2_0_13/todo/bugs_mp

#################
# mod_perl bugs #
#################

* local %ENV doesn't work, see t/modperl/local_ent.

* PerlOptions None needs to be implemented, see t/modperl/perl_options2.t

* PerlIOApache_flush() 
  Setting local $| = 0 doesn't work with regular print statements under ModPerl::*
  
  http://p6m7g8.net/MP2/84625
  http://www.gossamer-threads.com/lists/modperl/dev/85365
  [pgollucci volunteers]

* $r->rflush doesn't work. see:
  http://marc.theaimsgroup.com/?l=apache-modperl&m=103847990813285&w=2
  I also see a weird behavior where it does sends FLUSH buckets but
  they all seem to fall through the data, thus not really flushing
  anything. this can be easily reproduced with MyApache::FilterSnoop.

  See also
  http://www.gossamer-threads.com/lists/modperl/dev/84744?search_string=%23%7C%2C%20flushing%2C%20etc;#84743
  for a related $| but not the same issue.
  [pgollucci volunteers]

* early pool destruction issues
  http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=108872944815382&w=2

* PassEnv/SetEnv propogation in <Perl> section 
  http://www.gossamer-threads.com/archive/mod_perl_C1/dev_F4/%5BMP2_BUG%5D_PerlPassEnv_issues_P70500/

* there was a report about PerlRun leaking memory. the reporter didn't
  give any more details, but I suspect that it's due to
  ModPerl::Util::unload_package() which perfectly fits the timing when
  the leak was introduced (when PerlRun started to use unload_package).
  
  Report: http://gossamer-threads.com/lists/modperl/modperl/77162

* most of the xs wrappers print no "Usage: " when wrong args/wrong
  number of args are passed, would be nice to add the usage message
  whenever incorrect arguments error is logged. e.g., when
  APR::URI->parse() gets the wrong first arg (non-pool) it prints:

    p is not of type APR::Pool at ...

  whereas it's not so obvious that the function expected the pool
  object, neither it specifies which ("arg number") of the arguments
  is wrong.

  possible solution: add a new field to the map files, which will be
  used as a usage message whenever an argument error occurs.

* 'SetHandler modperl' doesn't reset $|, so if anything turns it on
  anywhere, it's going to stay that way. Meaning excessive flushing
  probably causing a performance hit. I've tried to add the code to
  reset it, but this requires getting a perl interpreter at the early
  stage and it breaks several filter tests, which has relied before on
  the coincidence that both the response handler and the filter were
  run by the same interpreter (in particular this breaks the code
  where push_handlers() uses a string as a handler, rather a CODE
  reference, see t/filter/TestFilter/both_str_rec_add.pm, to
  reproduce the problem, simply s/modperl/perl-script/)


* Apache::PerlSection->dump() will not preserve tied'edness. This is
  handled proprely in Storable, so either switch dump/restore to
  non-human readable (-0.5) or borrow the same logic to dump/restore
  tied objects.



* Apache::Log compat issues:

  Apache->warn, Apache::warn, Apache::Server->warn and
  Apache->Apache::Server->log_error are all doing:
     s = modperl_global_get_server_rec();
  and this function is thread safe only during the startup.

  possible solutions:

  1) enforce that these functions are used only at the server startup

  2) require +GlobalRequest, which gives us r->server, now thread
     safe (though slow).

  3) drop them all from the API and move to compat. 
     [remember that Apache::warn is needed for registry scripts to
     override warn()]

  For Apache::warn and registry, the solution is to supply
  GLOBAL::CORE::warn for the current request and get $r inside of it
  and]

  Report: Message-ID: <Pine.LNX.4.33.0206201011070.2590-100000@mako.covalent.net>
  Status: <img alt="Doug, contemplating">

* see if we can avoid touching environ[] until a fork() from Perl
  happens

* Apache::Status prints a bogus filename via B::CV (e.g. from the test
  suite)

    http://localhost:8529/status/perl/APR::Brigade::bootstrap/FUNCTION?cv_dump
    Subroutine info for APR::Brigade::bootstrap
    File: xYµ
    Package: APR::Brigade
    ...

  notice the bogus filename. For some reason this problem doesn't
  exist with APR::Bucket:

    http://localhost:8529/status/perl/APR::Bucket::bootstrap/FUNCTION?cv_dump

  I have tested that the bogus filename comes from $obj->FILE in
  Apache::Stats::cv_file, where $obj is blessed into B::CV.

  The problem has been noticed with threaded 5.8.1 perl, didn't test
  any other builds.

  Apparently it's a known to p5p problem:
  http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-08/msg00514.html
  http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-11/msg01126.html

  Report:   
  http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106893251911930&w=2
  Priority: Low 

* mpxs_Apache2__RequestRec_GETC in Apache_RequestIO.h is out to be
  reimplemented similar to read() w/o using the deprecated
  client_block interface

* Segfaults under Apache::Reload (could be uncovering a bug in mp):
  http://marc.theaimsgroup.com/?t=111145169900002&r=1&w=2
  owner: gozer
-