blob: e0e9412e608eb7cebf78f9a392d6fa0bb1a220ec [file] [log] [blame]
# 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::*
[pgollucci volunteers]
* $r->rflush doesn't work. see:
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;#84743
for a related $| but not the same issue.
[pgollucci volunteers]
* early pool destruction issues
* PassEnv/SetEnv propogation in <Perl> section
* 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).
* 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/, 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
Report: Message-ID: <>
Status: <img alt="Doug, contemplating">
* see if we can avoid touching environ[] until a fork() from Perl
* Apache::Status prints a bogus filename via B::CV (e.g. from the test
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:
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:
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):
owner: gozer