The key to making open source work well is that while it is hard to distribute development, the larger task of debugging can be tackled by many. You have found a bug in Perl, or in one of your modules. It appears that this bug is triggered in global destruction (you execute to your last line before hitting it). This bug is in underlying C code and is likely to be beyond your current resources to solve. It may well not be known about. Therefore right now you are in a position to contribute to the Perl community, and the valuable contribution that you can make is a good test case, and a good bug report.
What that means is producing as small an example as you can that produces the problem. Reduce your code as much as possible. Eliminate any modules that you can elminate. Then contact the maintainers with your report. And be prepared to get back strange questions which you should also try to answer. (BTW as a WAG, the problem is in your database drivers.)
No, producing that small case probably won't be easy. But it is easier for you than anyone else. And if you can create a small, reproducable case, then others can go to work on it.
If you don't do this, then when you install later revs of Perl and your modules, you will continue to get the same error. Plus someone else is going to hit it and duplicate the effort and pain you have gone through trying to figure out what is happening.
If you do come up with a good bug report, I can't promise that it will be fixed, but I can say that it has a good chance of happening. And if it doesn't get tackled, it will represent a good task for getting someone else involved.
BTW if you cannot come up with a good bug report, what is almost as good is to come up with two almost identical scripts, one with and one without the problem, but both of which someone can install from scratch very easily.
In reply to Re (tilly) 1: Memory Error
by tilly
in thread Memory Error
by markwild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |