Re (tilly) 1: Memory Error

What they said.

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.

Comment on Re (tilly) 1: Memory Error

Replies are listed 'Best First'.
Re: Re (tilly) 1: Memory Error by markwild (Sexton) on Apr 04, 2001 at 09:39 UTC
Tilly, et al, I very much appreciate the time you took to lay this out for me. I am such a huge fan of open source software (veteran of Two Perl Conferences, planning my third!) that I am surprised I didn't see the entire picture. I was looking for the community to benefit me, not the other way around. For that, to the community, I apologize. I'll do my best to distill the problem down to a reproducible and distributable chunk. The program basically uses DBI to connect to an Oracle 7.3 database and a MS SQL 7 database and moves data between them. The queries it uses to move the data back and forth are stored in a table. So it reads this query table, stores its data in a hash, then does select and insert queries (the ones stored in the hash) on opposite databases to move the data. (Neato, eh?) The tricky part is that the data (and the queries) are proprietary to my customer, so I can't just post all that. I'll have to generalize it somehow. At the present time, the problem has mysteriously vanished. I can't explain why or how, but while I was working with the software today, it was gone. I'm quite certain it will resurface, and when it does, I'll save that version of the software and try to pare it down. Thanks again for your time and attention. --Mark (prodigal open-sourcer)	[reply]

Replies are listed 'Best First'.

Re: Re (tilly) 1: Memory Error
by markwild (Sexton) on Apr 04, 2001 at 09:39 UTC

I very much appreciate the time you took to lay this out for me. I am such a huge fan of open source software (veteran of Two Perl Conferences, planning my third!) that I am surprised I didn't see the entire picture. I was looking for the community to benefit me, not the other way around.

For that, to the community, I apologize.

I'll do my best to distill the problem down to a reproducible and distributable chunk. The program basically uses DBI to connect to an Oracle 7.3 database and a MS SQL 7 database and moves data between them. The queries it uses to move the data back and forth are stored in a table. So it reads this query table, stores its data in a hash, then does select and insert queries (the ones stored in the hash) on opposite databases to move the data. (Neato, eh?) The tricky part is that the data (and the queries) are proprietary to my customer, so I can't just post all that. I'll have to generalize it somehow.

At the present time, the problem has mysteriously vanished. I can't explain why or how, but while I was working with the software today, it was gone. I'm quite certain it will resurface, and when it does, I'll save that version of the software and try to pare it down.

Thanks again for your time and attention.

--Mark (prodigal open-sourcer)

[reply]