Test cleanups & New SEGV forking test reproduction

[ancientwizard]

I have fixed all DBD::Oracle bugs (I could detect). I have this remaining
SEGV fault within Perl itself.

ADDED: Additional forking test that reproduces SEGV
within Perl 5.30.3+ using Oracle 19, 21 & 23. I've only tested
with these combinations.

$ gdb $(which perl)
 -- snip --
(gdb) run t/92-segv-fork.t
 -- snip --

Thread 2 "perl" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff1cc4680 (LWP 9807)]
0x000055555562e610 in Perl_csighandler3 (sig=17, sip=0x0, uap=0x0) at mg.c:1601
1601	           (PL_signals & PERL_SIGNALS_UNSAFE_FLAG))
(gdb) list
1596	           sig == SIGSEGV ||
1597	#endif
1598	#ifdef SIGFPE
1599	           sig == SIGFPE ||
1600	#endif
1601	           (PL_signals & PERL_SIGNALS_UNSAFE_FLAG))
1602	        /* Call the perl level handler now--
1603	         * with risk we may be in malloc() or being destructed etc. */
1604	    {
1605	        if (PL_sighandlerp == Perl_sighandler)
(gdb) bt
    futex_word=0x5555563af118) at ./nptl/futex-internal.c:57
    at ./nptl/futex-internal.c:87
    abstime=abstime@entry=0x7ffff1cc3e00, private=private@entry=0) at ./nptl/futex-internal.c:139
    at ./nptl/pthread_cond_wait.c:503
(gdb)

[djzort]

Thanks muchly. I will get a new dev release out

[ancientwizard]

I'm really looking forward to the day I can dispose of my fork. We're not there yet.

I've opened Perl/perl5#23326 because I'm not certain this SEGV is a DBD::Oracle specific issue. I've already received a response suggesting that the Oracle library is creating its own threads -YUCK

This give me something to pursue with Oracle from the office. I should be able to write a C program that reproduces the issue with Perl. The moment they hear Perl or Python etc their ears turn off and refuse to help. I'm certain the fee my org pays is no small amount. Perhaps I should have kept that to myself. 😉 😜

I've seen the other comments and yes I'll continue to improve the test so it makes the windows experience tolerable