t/15threads.t intermittent SEGV #188
Description
I have only tested on Ubuntu, CentOS and RHEL8/9 (same SEGV)
The SEGV is intermittent, and I fail to see how this is an actual DBD::Oracle issue; or rather FAIL to see that it's an OCI call issue.
If the issue is with the my_perl OR the file handle that's beyond my pay grade. The C string buffer and the SIZE smell correct. I had hoped to fix this and perhaps correct a SEGV I'm seeing at work. Time to circle back to (in-office) APP and see where that SEGV is coming from.
It is always tied to the OCISessionEnd() after it's called as a SUCCESS - SIGH!
Though I'm the one that ADDED the wrapper around the call to make it smell like everything else.
OCIServerDetach_log_stat( imp_dbh, imp_dbh->srvhp, imp_dbh->errhp, OCI_DEFAULT, status );
$ gdb $(which perl)
-- snip (noise) --
(gdb) run t/15threads.t
Starting program: /a-perl/perl-5.40.2-oic-23/bin/perl t/15threads.t
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff15ff680 (LWP 27039)]
[New Thread 0x7fffe45ff6c0 (LWP 27040)]
[Thread 0x7fffe45ff6c0 (LWP 27040) exited]
[New Thread 0x7fffe45ff6c0 (LWP 27041)]
[Thread 0x7fffe45ff6c0 (LWP 27041) exited]
[New Thread 0x7fffe45ff6c0 (LWP 27042)]
[Thread 0x7fffe45ff6c0 (LWP 27042) exited]
[New Thread 0x7fffe45ff6c0 (LWP 27043)]
[Thread 0x7fffe45ff6c0 (LWP 27043) exited]
[New Thread 0x7fffe45ff6c0 (LWP 27044)]
[Thread 0x7fffe45ff6c0 (LWP 27044) exited]
Thread 1 "perl" received signal SIGSEGV, Segmentation fault.
0x00005555556560fe in Perl_PerlIO_write (my_perl=0x5555559ea2a0, f=0x40, vbuf=0x5555568823b0, count=78) at perlio.c:2015
2015 Perl_PerlIO_or_fail(f, Write, -1, (aTHX_ f, vbuf, count));
(gdb) list
2010 SSize_t
2011 Perl_PerlIO_write(pTHX_ PerlIO *f, const void *vbuf, Size_t count)
2012 {
2013 PERL_ARGS_ASSERT_PERLIO_WRITE;
2014
2015 Perl_PerlIO_or_fail(f, Write, -1, (aTHX_ f, vbuf, count));
2016 }
2017
2018 int
2019 Perl_PerlIO_seek(pTHX_ PerlIO *f, Off_t offset, int whence)
(gdb) print vbuf
$3 = (const void *) 0x5555568823b0
(gdb) x/s vbuf
0x5555568823b0: "\tOCISessionEnd(5555567a56b0,5555567a57b0,5555567a74e0,mode=DEFAULT 0)=SUCCESS\n"
(gdb) print (int)strlen(vbuf)
$4 = 78
(gdb)
Perhaps this was a known issue and why the calls were (bare). A prior comment I think existed about errors. I may have assumed it was simply saying "any errors at this point are moot so why bother". It may have been poorly stating "I don't want to blowup while trying to show errors". Removing the wrapper logging leaves zero chance to SEGV. -HUMPH
A guess; file-handle race condition? (but it's Perl, you'd think it would silently do nothing).
Oh wait; what if this is during a GLOBAL shutdown AKA END { ... }; I've run into issues with doing things that are far too sophisticated to handle in END's and Perl can get NASTY at you.