Re: mod_cgi bug
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:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_cgi bug
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
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:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_cgi bug
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
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:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_cgi bug
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
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: 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. ... 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:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
