On Wed, Apr 07, 2004 at 09:51:56AM -0700, Stas Bekman wrote:
Joe Orton wrote:
...
t/filter/both_str_con_add.t 4 2 50.00% 3-4 t/protocol/echo.t 3 1 33.33% 3 t/protocol/echo_filter.t 3 1 33.33% 3
These three has to do with some bug in APR sockets. All three implement a protocol handler which reads/writes raw connection sockets. It works just fine on several unices, but fails on Solaris and OSX.
any of these known failures and/or worth looking at?
They are known failures, but nobody is working on them. If you would like to help to resolve these, that would be fantastic. I can guide you of what to loook at if you decide to help.
Hey, it's a rainy evening... how far have you debugged this so far then?
I haven't at all, since they don't fail on linux. The only additional information I have from one of the users on Solaris that IO::Socket works fine on its own (which is what happens on the client side), so it must be a fault of the APR socket API on the server side. And the perl glue just calls C functions, so it's probably some C API problems.
So what I suspect is that the client socket using perl's IO::Socket works fine , and one needs to breakpoint into APR::Socket and run the echo.t test and step through to see where the data doesn't get through. echo.t is the simplest possible test, perfectly suitable for this job.
Please take a look at the precooked gdb scripts to make your debugging easier: http://perl.apache.org/docs/2.0/devel/debug/c.html#Precooked_gdb_Startup_Scripts and http://perl.apache.org/docs/2.0/devel/debug/c.html#Debug_notes in general (but you probably know most of this already :)
But it's good to see that the rest is working. Also please test the LFS thingy with httpd-2.1, as you said it'd have worked just fine with 2.0, but not with 2.1 before we did all these recent changes.
The CFLAGS thing with using APR HEAD regardless of whether Perl itself was built with LFS. I'm now building 5.8.3 with -Duselargefiles for comparison.
oh, you are using APR head with httpd 2.0?
the core dump was actually created by the 'perl' binary rather than 'httpd'...
core dump? Can we see a backtrace?
FWIW, it looked like this, not sure I believe it really got into libthread.
#0 0xdfddf70c in _bind_guard () from /usr/lib/libthread.so.1 #1 0xdffeae65 in ?? () #2 0xdfff0c7f in ?? () #3 0xdffe6559 in ?? () #4 0x80a46a5 in Perl_pp_entersub () #5 0x80633f9 in S_call_body () #6 0x80631d2 in Perl_call_sv () #7 0x80aa594 in Perl_sv_clear () #8 0x80aaacd in Perl_sv_free () #9 0x80bb90d in Perl_free_tmps () #10 0x80628e1 in perl_run () #11 0x8060295 in main () #12 0x80600d7 in _start ()
looks like some corrupted frames core. we need to figure out the cause. running:
t/SMOKE -v
will check for the core file after each test is run, so it may help to pinpoint the cause.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
