Re: Segfault in threaded program after upgrade to DBI 1.620
Here's the backtrace log. Matt On Thu, May 10, 2012 at 10:00 PM, Matthew Musgrove wrote: > 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 > backtrace.log Description: Binary data
Segfault in threaded program after upgrade to DBI 1.620
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