Re: Segfault in threaded program after upgrade to DBI 1.620
Ah, great. Thanks Matt. [Note to self: It's worth checking the bug tracker for updates from users.] DBI 1.621 is on it's way. Tim. On Mon, May 21, 2012 at 10:23:44AM -0500, Matthew Musgrove wrote: Tim, Yes, I updated that bug report last week to report that the patch worked for me. Thanks, Matt On Mon, May 21, 2012 at 7:53 AM, Tim timbo@timac.local wrote: Hello Matthew. It's worth checking the bug tracker for known problems. Your problem sounds like https://rt.cpan.org/Public/Bug/Display.html?id=77137 for which we have a patch attached to the ticket. I'm about to make a trial release of 1.621 with that patch included. I'd be grateful if you could test the patch ASAP, or else test the trial release. Thanks. Tim.
Re: Segfault in threaded program after upgrade to DBI 1.620
Hello Matthew. It's worth checking the bug tracker for known problems. Your problem sounds like https://rt.cpan.org/Public/Bug/Display.html?id=77137 for which we have a patch attached to the ticket. I'm about to make a trial release of 1.621 with that patch included. I'd be grateful if you could test the patch ASAP, or else test the trial release. Thanks. Tim.
Re: Segfault in threaded program after upgrade to DBI 1.620
Tim, Yes, I updated that bug report last week to report that the patch worked for me. Thanks, Matt On Mon, May 21, 2012 at 7:53 AM, Tim timbo@timac.local wrote: Hello Matthew. It's worth checking the bug tracker for known problems. Your problem sounds like https://rt.cpan.org/Public/Bug/Display.html?id=77137 for which we have a patch attached to the ticket. I'm about to make a trial release of 1.621 with that patch included. I'd be grateful if you could test the patch ASAP, or else test the trial release. Thanks. Tim.
Re: Segfault in threaded program after upgrade to DBI 1.620
I've retested with DBI 1.617 and DBI 1.618. Our program does not segfault with either of them so it has to be something specific to the 1.620 changes. Matt On Thu, May 10, 2012 at 10:00 PM, Matthew Musgrove mr.musk...@gmail.comwrote: 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
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
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 mr.musk...@gmail.comwrote: 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
