On 2011.11.10 7:15 AM, H.Merijn Brand wrote:
Yes, there indeed is a core
(gdb) where
#0 0xc000000000258c70:0 in free+0x1d0 () from /usr/lib/hpux64/libc.so.1
#1 0x400000000017f7e0:0 in Perl_safesysfree () at util.c:262
#2 0x40000000000d0ab0:0 in perl_destruct () at perl.c:871
#3 0x400000000009a740:0 in main () at perlmain.c:119
I however do not understand why prove seems to be safe, but make test
is not
First, try to replicate everything "make test" is doing with prove.
For starters, even though test processes are supposed to remain separate,
other tests could be interfering and the segfault only happens when you run
the whole test suite. So run the whole test suite.
prove -wbr t
I see you're firing off child processes, if you're doing the same in the
previous test it could be that they're not finished from the previous test
starts. It could be that your database is in a bad state.
The second major difference is "make test" sets the PERL_DL_NONLAZY flag which
is helpful for XS testing, so add that into the mix.
PERL_DL_NONLAZY=1 prove -wbr t
If that doesn't work, go the other way. Strip out everything you can,
including prove, and start adding things in. When you want verbose test
output, don't use prove -v, just run the program.
perl -w -Mblib t/21-uni-regex.t
If that doesn't replicate, try adding in subtle things which are different
between 'make test', 'prove' and running manually.
Try having STDOUT go to a pipe instead of a TTY.
perl -w -Mblib t/21-uni-regex.t | cat
Try the same for input.
echo | perl -w -Mblib t/21-uni-regex.t
Try both.
echo | perl -w -Mblib t/21-uni-regex.t | cat
Or it could be that prove is setting environment variables which Test::Harness
is not, check them. They could be affecting your shell command.
--
124. Two drink limit does not mean first and last.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
