We have this threaded program that runs as a daemonized service and it's been happy for quite a while using DBI 1.616 and DBD::Oracle 1.30. Last week, I updated DBI to 1.620 and DBD::Oracle 1.44 and when I restarted the service, it segfaulted as soon as it created a new thread. I was pretty sure that it wasn't in DBD::Oracle because I had tested a prerelease of the new code and didn't have any problems with it. I reverted it back to DBI 1.616 and DBD::Oracle 1.30 and when I restarted the service, it was happy again. Next I updated DBI to 1.620 and left DBD::Oracle alone. Again, it segfaulted as soon as it created a new thread. It isn't my code so there could be a bug or three lurking in there waiting to attack but as I said, it's been working just fine. The only change was to DBI. I reverted DBI back to 1.616 and decided to wait (you know, to see if anyone would report anything).
Today, I had a little free time and decided to try it again. It took some coaxing but I finally got it create a core dump (after setting DAEMON_COREFILE_LIMIT=" unlimited"). I loaded the core dump in gdb and did a backtrace. It looks like it segfaults in dbi_ima_dup. Unfortunately, this perl didn't have debugging enabled. I compiled a new copy of perl (same version and I think the same flags except with debugging), installed the same modules for it and created another core dump. I logged 'backtrace', 'info registers' and 'thread apply all backtrace' to separate files. This was my first time using gdb so that was interesting. I don't really know what sort of information you need so... yeah. I'm attaching output from perl -V (from both copies of perl) and 'info registers'. I'll send a reply with the backtrace log next. What other information do I need to provide? Does anyone have any tips or pointers on how I can debug this further? Matt
perl.log
Description: Binary data
perld.log
Description: Binary data
registers.log
Description: Binary data
