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.