Re: cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
Randy Kobes wrote: On Mon, 17 Nov 2003, Geoffrey Young wrote: I dunno, but I am afraid that stuff like device, inode, nlink and such might not work similarly on non-Unixes.. These tests most likely need to be a bit more OS-specific to avoid failures on those OSes yes, I meant to follow this up with an email saying that I would quickly fix any os related issues once randy et al get the chance to play with them and expose where APR is different than perl. but I didn't want to just skip them on win32 before I knew where the issues were, and testing checked in stuff is just easier :) That's true ... On Win32, inode, device, user, and group are all defined, but these tests fail as written, as the returned values are different ... The same thing goes for the test involving WEXECUTE. Probably one might come up with what these returned values would be on Win32, but I'm wondering if it's worth it - from what I gather, some of these might depend on the Win32 flavour being used (eg, on Win9?, any readable file is [almost always] executable). Perhaps we could just skip these tests on Win32: if the semantics are really that dissimilar, I guess it makes the most sense to just skip them, especially since the concept of user and group aren't really meaningful on win32. I'm glad to see the RW stuff work, though :) your patch looks good to me, so commit at will. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
On Tue, 18 Nov 2003, Geoffrey Young wrote: > Randy Kobes wrote: > > On Mon, 17 Nov 2003, Geoffrey Young wrote: > > > >>>I dunno, but I am afraid that stuff like device, inode, > >>>nlink and such might not work similarly on non-Unixes.. > >>>These tests most likely need to be a bit more > >>>OS-specific to avoid failures on those OSes > >> > >>yes, I meant to follow this up with an email saying that I > >>would quickly fix any os related issues once randy et al > >>get the chance to play with them and expose where APR is > >>different than perl. but I didn't want to just skip them > >>on win32 before I knew where the issues were, and testing > >>checked in stuff is just easier :) > > > > That's true ... On Win32, inode, device, user, and group are > > all defined, but these tests fail as written, as the > > returned values are different ... The same thing goes for > > the test involving WEXECUTE. Probably one might come up with > > what these returned values would be on Win32, but I'm > > wondering if it's worth it - from what I gather, some of > > these might depend on the Win32 flavour being used (eg, on > > Win9?, any readable file is [almost always] executable). > > Perhaps we could just skip these tests on Win32: > > if the semantics are really that dissimilar, I guess it > makes the most sense to just skip them, especially since > the concept of user and group aren't really meaningful on > win32. I'm glad to see the RW stuff work, though :) > > your patch looks good to me, so commit at will. OK, I'll do that - thanks ... It is great that the others (RW, size, times) do work. I think the thing with the user/group, indode/device, and execute is that, since there's no universally obvious way to deal with these on Win32, APR does one thing and Perl does another, and the two don't always agree with each other (and also, as I indicated before, the specific disagreement may also depend on the Win32 flavour). However, the fact that the $r->finfo->fname returns undef on Win32 is something that should be tracked down. At the moment I don't see where the trouble lies, as it's statting the right file; it's just that the name isn't getting recorded. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
However, the fact that the $r->finfo->fname returns undef on Win32 is something that should be tracked down. At the moment I don't see where the trouble lies, as it's statting the right file; it's just that the name isn't getting recorded. oh, I missed that - yes, that ought to be tracked down. are you on apr@ and can post it there? if not, I'll see if I can't track down bill rowe here (at apachecon) and talk to him about it. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
Geoffrey Young wrote: However, the fact that the $r->finfo->fname returns undef on Win32 is something that should be tracked down. At the moment I don't see where the trouble lies, as it's statting the right file; it's just that the name isn't getting recorded. oh, I missed that - yes, that ought to be tracked down. are you on apr@ and can post it there? if not, I'll see if I can't track down bill rowe here (at apachecon) and talk to him about it. actually, I see where the problem is, so I'll post it and report back. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
On Tue, 18 Nov 2003, Geoffrey Young wrote: > > However, the fact that the $r->finfo->fname returns undef on > > Win32 is something that should be tracked down. At the > > moment I don't see where the trouble lies, as it's statting > > the right file; it's just that the name isn't getting > > recorded. > > oh, I missed that - yes, that ought to be tracked down. > are you on apr@ and can post it there? if not, I'll see > if I can't track down bill rowe here (at apachecon) and > talk to him about it. No, I'm not on apr@ ... And actually, I'm not sure if it's a problem on the Perl side or the apr side ... I can't see what can go wrong on the Perl side, though, given, for example, $r->finfo gets the size of the file correct. But stranger things have happened ... If you do see bill rowe, it would be good to know if he knows about this - there was a post on the apr-dev list on 2003-01-10 (that he responded to) about a patch to set both info.name and info.fname on Win32, but it looks like that there were some problems with the patch. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl segfaults when also using mod_rewrite
When I do that, the port doesn't even seem to open. Here's what I do: [EMAIL PROTECTED] mod_perl-1.99_11]# gdb /usr/local/www/apache-2.0.48/bin/httpd GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run -X -d /usr/local/www/apache-2.0.48 Starting program: /usr/local/www/apache-2.0.48/bin/httpd -X -d /usr/local/www/apache-2.0.48 [New Thread 16384 (LWP 28385)] ...and I can't even attach to the port then. Any ideas? --Aaron Bobber Cheng wrote: 1. compile with debug flag First make sure u install gdb, then compile httpd and modperl in debug mod, configure apache2 as: ./configure --enable-maintainer-mode and ur custom flages configure mod_perl ad: perl "Makefile.PL MP_DEBUG=1 and ur custom flages" compile and install them to the right place. 2. run apache2 in gdb $APACHE2_HOME is ur apache installed directory such as /usr/local/apache2 then run gdb as: gdb $APACHE2_HOME/bin/httpd (gdb) run -X -d $APACHE2_HOME apache2 should run. 3. report the backtrace visit ur page us usally, when server segfaults, gdb will tell ur where. u just type (gdb) backtrace and report the result. hope it could help u. [EMAIL PROTECTED] wrote: I'm using apache v2.0.48 and have confirmed that the problem exists with both mod_perl v1.99_11 and v1.99_12-dev in CVS. If I simply use "RewriteEngine On", mod_perl works fine. If I use "RewriteEngine OnRewriteRule ^/(.*) /index.pl/$1 [PT]" (or anything similar), the apache server immediately segfaults, displays nothing, and logs nothing useful (even in debug). This does not happen with mod_perl v1.99_10, although for reasons unrelated to mod_perl I'm actually stuck using v1.99_09 right now, which works more or less fine with this configuration. I'm using apache compiled from source on RedHat 8.0, with perl-5.8.0-88.3 and GCC v3.3.2. Unfortunately I'm not a C programmer, or I probably would have been able to send more useful information. I tried to follow the instructions on debugging mod_perl C internals and get a core file, but I couldn't get that to work either. Any ideas? Thanks. --Aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
If you do see bill rowe, it would be good to know if he knows about this - there was a post on the apr-dev list on 2003-01-10 (that he responded to) about a patch to set both info.name and info.fname on Win32, but it looks like that there were some problems with the patch. I just spent 30 minutes with him on this and it seems that it's not that complex, but there are a few caveats that need to be noted. nonetheless, he said to watch apr space over the next day or so for a fix :) so, as always, thanks randy! --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl segfaults when also using mod_rewrite
Aaron Paetznick wrote: When I do that, the port doesn't even seem to open. Here's what I do: [EMAIL PROTECTED] mod_perl-1.99_11]# gdb /usr/local/www/apache-2.0.48/bin/httpd GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run -X -d /usr/local/www/apache-2.0.48 Starting program: /usr/local/www/apache-2.0.48/bin/httpd -X -d /usr/local/www/apache-2.0.48 [New Thread 16384 (LWP 28385)] ...and I can't even attach to the port then. Any ideas? port? Did you mean thread? If you are running a prefork mp you should do: gdb> run -DONE_PROCESS -DNO_DETATCH If a worker/winnt mpm, then: gdb> run -DONE_PROCESS -DNO_DETATCH -DPERL_USEITHREADS For the complete info please read: http://perl.apache.org/docs/2.0/devel/debug/c.html#Debug_notes __ Stas BekmanJAm_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]
Re: mod_perl segfaults when also using mod_rewrite
Stas Bekman wrote: gdb> run -DONE_PROCESS -DNO_DETATCH If a worker/winnt mpm, then: gdb> run -DONE_PROCESS -DNO_DETATCH -DPERL_USEITHREADS I need to learn to spell, please perl -pi -e 's|DETATCH|DETACH|g' << THIS_MESSAGE __ Stas BekmanJAm_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]
Re: cvs commit: modperl-2.0/t/response/TestAPR finfo.pm
On Tue, 18 Nov 2003, Geoffrey Young wrote: > > If you do see bill rowe, > > it would be good to know if he knows about this - there was > > a post on the apr-dev list on 2003-01-10 (that he responded > > to) about a patch to set both info.name and info.fname on > > Win32, but it looks like that there were some problems with > > the patch. > > I just spent 30 minutes with him on this and it seems that > it's not that complex, but there are a few caveats that > need to be noted. nonetheless, he said to watch apr space > over the next day or so for a fix :) > > so, as always, thanks randy! > > --Geoff Great So for now, should we skip the fname test on Win32 until a future Apache2 version comes with the patch? -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: mod_perl-1.99_11 on HP-UX 11.22]
forwarding this to where this message belongs Original Message Subject: mod_perl-1.99_11 on HP-UX 11.22 Date: Tue, 18 Nov 2003 15:16:49 -0800 (PST) From: TJ Saunders <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hello, Stas. I'm building mod_perl-1.99_11 using Apache 2.0.48 and perl 5.8.2 on HP-UX 11.22 using HP's C compiler -- everything built just fine. However, when I went to run the mod_perl test suite, quite a few of the tests failed. The error in the t/logs/error_log was the "Can't locate foo in @INC (...)" message, which unfortunately is not verbose enough to pinpoint the culprit. Using tusc, I eventually tracked it down to open() returning EMFILE for some of the test suite's require()s. Turns out the default number of per-process open files in the shell was quite low: 60. Setting 'ulimit -n 1024' made the tests pass successfully. If possible, could this checking/setting of this resource limit be done by TestRun.pm, similarly to what is done for the core size limit, so that it doesn't bite other developers? Cheers, TJ --- TJ <[EMAIL PROTECTED]> --- -- __ Stas BekmanJAm_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]
Re: [Fwd: mod_perl-1.99_11 on HP-UX 11.22]
Stas Bekman wrote: forwarding this to where this message belongs Original Message Subject: mod_perl-1.99_11 on HP-UX 11.22 Date: Tue, 18 Nov 2003 15:16:49 -0800 (PST) From: TJ Saunders <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hello, Stas. I'm building mod_perl-1.99_11 using Apache 2.0.48 and perl 5.8.2 on HP-UX 11.22 using HP's C compiler -- everything built just fine. However, when I went to run the mod_perl test suite, quite a few of the tests failed. The error in the t/logs/error_log was the "Can't locate foo in @INC (...)" message, which unfortunately is not verbose enough to pinpoint the culprit. Using tusc, I eventually tracked it down to open() returning EMFILE for some of the test suite's require()s. Turns out the default number of per-process open files in the shell was quite low: 60. Setting 'ulimit -n 1024' made the tests pass successfully. If possible, could this checking/setting of this resource limit be done by TestRun.pm, similarly to what is done for the core size limit, so that it doesn't bite other developers? Thanks for tracing this problem, TJ. I guess we could do what you propose (as we already use ulimit to allow core files), though I'm not entirely sure that it's safe to hardcode it as 1024. What if the system's hard limit is set to a lower number? What if someone else's test suite will need to open more than 1024 files? (since Apache-Test is used by many other projects) Therefore I think we should set it to one of the following: hard, soft, or unlimited. Probably "hard" is the best choice. I'm not sure how cross-platform this is, but that's what my bash manpage on linux suggests. Though it doesn't see to work for -n. Of course one could check /proc/sys/fs/file-nr but again I don't think this is cross-platform. Further suggestions are very welcome. __ Stas BekmanJAm_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]
Re: [mp2] segfaults when using "include" filter w/mod_perl
Tyler 'Crackerjack' MacDonald wrote: Hello, Thanks for taking the time to look at this: Thanks for reporting this Tyler, I'm looking at this issue, though I may come back to you only on Thu, once I'm back from ApacheCon. __ Stas BekmanJAm_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]
