You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Doug MacEachern <do...@covalent.net> on 2001/08/12 21:40:07 UTC
mod_cgi bug
if POST data is written to a cgi script that does not read it, httpd dumps
core:
(gdb) where
#0 0x40169124 in __libc_write () from /lib/libc.so.6
#1 0x4009dadc in __DTOR_END__ () from /lib/libpthread.so.0
#2 0x80c6217 in apr_file_write (thefile=0x822271c, buf=0xbfffb780,
nbytes=0xbfffb740) at readwrite.c:253
#3 0x809ba0b in cgi_handler (r=0x82211e4) at mod_cgi.c:691
#4 0x80a3d86 in ap_run_handler (r=0x82211e4) at config.c:186
#5 0x80a41e6 in ap_invoke_handler (r=0x82211e4) at config.c:344
#6 0x8093bcc in process_request_internal (r=0x82211e4) at
http_request.c:378
#7 0x8093ca6 in ap_process_request (r=0x82211e4) at http_request.c:444
#8 0x808ea26 in ap_process_http_connection (c=0x821f2a4) at
http_core.c:287
#9 0x80ab662 in ap_run_process_connection (c=0x821f2a4) at
connection.c:82
#10 0x80a2a36 in child_main (child_num_arg=0) at prefork.c:821
#11 0x80a2ae0 in make_child (s=0x81bab64, slot=0) at prefork.c:857
#12 0x80a2bd7 in startup_children (number_to_start=1) at prefork.c:931
#13 0x80a2f2b in ap_mpm_run (_pconf=0x81b989c, plog=0x81f45ec,
s=0x81bab64)
at prefork.c:1146
#14 0x80a768e in main (argc=6, argv=0xbffffa64) at main.c:427
#15 0x400b9b5c in __libc_start_main (main=0x80a72b8 <main>, argc=6,
ubp_av=0xbffffa64, init=0x8073154 <_init>, fini=0x816a85c <_fini>,
rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbffffa5c)
at ../sysdeps/generic/libc-start.c:129
btw, if you're using httpd-test, its easy to reproduce.
in httpd-test/perl_framework run:
% t/TEST -d
to start under gdb, then in another xterm (same directory):
% t/TEST t/modules/cgi.t
or to get right to the point:
% t/TEST -post /modules/cgi/sh.sh content one=1
same happens with the perl scripts, if i add:
read STDIN, $buffer, $ENV{CONTENT_LENGTH} if $ENV{CONTENT_LENGTH};
the segv goes away.
QA online resources?
Posted by Stas Bekman <st...@stason.org>.
I've realized that very few people understand regression testing and other
QA terminology. I've been asked to explain some of these termins. I've
searched google, but there are too many hits which are not very useful
ones.
This seem to be a nice resource: http://www.sqatester.com/ Any comments
about this one, or any other useful online materials I can point people
to? Do you have your preferred short tutorial that covers the basics
(unit, covarage, black, white box testing, ...) ?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://localhost/ http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_cgi bug
Posted by Stas Bekman <st...@stason.org>.
On Mon, 13 Aug 2001, Doug MacEachern wrote:
> On Tue, 14 Aug 2001, Stas Bekman wrote:
>
> > what happens if user's system is configured not to dump a core file?
> > ulimit(1) and stuff... are we going to explain this to user? With an
> > explicit flag we can detect segv and nicely get the trace.
>
> how about reusing an existing flag, like '-d auto' ?
that's doable
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_cgi bug
Posted by Doug MacEachern <do...@covalent.net>.
On Tue, 14 Aug 2001, Stas Bekman wrote:
> what happens if user's system is configured not to dump a core file?
> ulimit(1) and stuff... are we going to explain this to user? With an
> explicit flag we can detect segv and nicely get the trace.
how about reusing an existing flag, like '-d auto' ?
Re: mod_cgi bug
Posted by Stas Bekman <st...@stason.org>.
On Mon, 13 Aug 2001, Doug MacEachern wrote:
> On Mon, 13 Aug 2001, Stas Bekman wrote:
>
> > OK for the new flag?
>
> i was thinking no flag at all, just run 't/TEST', Apache::TestRun::scan
> already looks for a core file, fire up gdb and get a stacktrace there.
what happens if user's system is configured not to dump a core file?
ulimit(1) and stuff... are we going to explain this to user? With an
explicit flag we can detect segv and nicely get the trace.
otherwise I agree with you.
so which flag should we use if at all?
> > Tell me the secret, how do you keep up with reading all these lists :(
>
> i can't keep up, buried in email right now.
:(
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_cgi bug
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 13 Aug 2001, Stas Bekman wrote:
> OK for the new flag?
i was thinking no flag at all, just run 't/TEST', Apache::TestRun::scan
already looks for a core file, fire up gdb and get a stacktrace there.
> were there any changes since then?
nope.
> Tell me the secret, how do you keep up with reading all these lists :(
i can't keep up, buried in email right now.
Re: mod_cgi bug
Posted by Stas Bekman <st...@stason.org>.
On Mon, 13 Aug 2001, Doug MacEachern wrote:
> On Mon, 13 Aug 2001, Stas Bekman wrote:
>
> > So if there is some ARGV, -d starts the gdb process via fork, a moment
> > before the test is fired, and the parent process redirects STDOUT to
> > STDERR so it won't mess up the gdb screen. or something similar, like just
> > working through the pipe in the forked process.
>
> if you can make that works so its still possible to interact with gdb
> (like making 't/TEST -b foo_function t/module/cgi.t' work), that would be
> killer. if you mean run the test and just get a stacktrace, that would be
> cool too, there's already a Devel::CoreStack module that could be hooked
> in. actually, i think Test::Harness already does tries that if you have
> Devel::CoreStack installed.
oh, did I volunteer to do that :) I'll give it a try
I'd probably leave the -d option as is, but add -I_am_lazy which will do
all the work for you. I want -d to work as before, because we want to
have an interactive gdb, whereas the new option will work with gdb behind
the walls.
OK for the new flag?
> > I'm sick of sending replies 'read SUPPORT' to people on the mod_perl list
> > who reports segv, without providing the calls trace. It's a known
> > fact, that people don't RTFM :(
>
> yep, me included.
if you get a chance to follow the 'mod_perl 2.0 doc project' thread, you
will see that we secretly spec out an ultra AI system, which will do all
the list's work for us. Now can we plan go skiing now?
> > Wouldn't it be cool to have ./t/TEST generate the calls trace for your on
> > segv (we already do scan for the core file), so fire gdb, generate the
> > trace and save it into a file, now use ./util/bugreport.pl and get the
> > email ready.
>
> for sure.
>> todo
> > Also did you see Devel::DebugInit::GDB on CPAN? Didn't try it yet, but it
> > says:
>
> see:
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-05/msg02213.html
>
> i'd really like to see that working properly, but it has been
> faster/easier to get by cluttering my ~/.gdbinit by hand.
were there any changes since then?
Tell me the secret, how do you keep up with reading all these lists :(
I've hardly time to browse the new-httpd list, in addition to some 15
other lists, but I'm afraid getting on the p5p list, I'll end up reading
mails all day and no time to code :( I guess that's the price that one has
to pay if you want to be involved in perl and apache at the same time.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://localhost/ http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_cgi bug
Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 13 Aug 2001, Stas Bekman wrote:
> So if there is some ARGV, -d starts the gdb process via fork, a moment
> before the test is fired, and the parent process redirects STDOUT to
> STDERR so it won't mess up the gdb screen. or something similar, like just
> working through the pipe in the forked process.
if you can make that works so its still possible to interact with gdb
(like making 't/TEST -b foo_function t/module/cgi.t' work), that would be
killer. if you mean run the test and just get a stacktrace, that would be
cool too, there's already a Devel::CoreStack module that could be hooked
in. actually, i think Test::Harness already does tries that if you have
Devel::CoreStack installed.
> I'm sick of sending replies 'read SUPPORT' to people on the mod_perl list
> who reports segv, without providing the calls trace. It's a known
> fact, that people don't RTFM :(
yep, me included.
> Wouldn't it be cool to have ./t/TEST generate the calls trace for your on
> segv (we already do scan for the core file), so fire gdb, generate the
> trace and save it into a file, now use ./util/bugreport.pl and get the
> email ready.
for sure.
> Also did you see Devel::DebugInit::GDB on CPAN? Didn't try it yet, but it
> says:
see:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-05/msg02213.html
i'd really like to see that working properly, but it has been
faster/easier to get by cluttering my ~/.gdbinit by hand.
Re: mod_cgi bug
Posted by Stas Bekman <st...@stason.org>.
On Sun, 12 Aug 2001, Doug MacEachern wrote:
[a snippet from a recent post to new-httpd]
> btw, if you're using httpd-test, its easy to reproduce.
> in httpd-test/perl_framework run:
> % t/TEST -d
> to start under gdb, then in another xterm (same directory):
> % t/TEST t/modules/cgi.t
Hmm, Doug, how about having one instance of a script that does everything?
% t/TEST -d t/modules/cgi.t
So if there is some ARGV, -d starts the gdb process via fork, a moment
before the test is fired, and the parent process redirects STDOUT to
STDERR so it won't mess up the gdb screen. or something similar, like just
working through the pipe in the forked process.
I know we know how to do that, but many people won't understand it. If we
make it really simple, we will get more added value from users [testers].
I was thinking to go even further in automating things:
I'm sick of sending replies 'read SUPPORT' to people on the mod_perl list
who reports segv, without providing the calls trace. It's a known
fact, that people don't RTFM :(
Wouldn't it be cool to have ./t/TEST generate the calls trace for your on
segv (we already do scan for the core file), so fire gdb, generate the
trace and save it into a file, now use ./util/bugreport.pl and get the
email ready.
Also did you see Devel::DebugInit::GDB on CPAN? Didn't try it yet, but it
says:
<quote>
Devel::DebugInit is aimed at C/C++ developers who want access to C macro
definitions from within a debugger. It provides a simple and automated way
of creating debugger initialization files for a specific project. The
initialization files created contain user-defined functions built from the
macro definitions in the project's header files.
...
</quote>
I thought that we might load the macros automatically when -d is used.
like curinfo and friends.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/