Such errors usually mean you are treading in the nether regions. For example, using fork or signals in Win32 Perl. XS modules (modules that have parts written in C) are also good suspects.

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.

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)

Can you at least print-debug or something and tell us the last couple of lines leading up to the crash?

--
$you = new YOU;
honk() if $you->love(perl)

Thanks for offerring to help. I wish I could do as you ask!
To dissect the 900-line script would take hours of work. It touches both Oracle and MS SQL7 databases and basically moves records between them.
That said, I really didn't intend on this being a script question as much as an interpreter question. I don't think the problem actually lies within the script, and I am holding out hope that perhaps someone else came across the same problem and resolved it somehow.
--MarkWild

No really. The error you got is a memory protection fault. That means that somewhere in perl the executable or in the modules added to perl that tie to it on a .so or .dll basis are making a mistake. Generally it is trying to access a variable that has already been destroyed by perl or stepping outside of a memory boundary set up by a string. As tye points out, signals can wind up trying to deal with bad data because they can catch perl in between critical steps in certain circumstances and leave things half finished.

Based on the error having two locations that are the same I'd bet on the interpreter having it's instruction pointer sent out to never-never land and trying to execute a portion of blank memory.

If you don't at least try no one will ever be able to help you with this problem. Really. I'm not kidding, the error you listed is among the most generic errors in the entire computer world. All it tells us is that something somewhere tried to do something in a place where it wasn't allowed.

Your line "perhaps someone else came across the same problem and resolved it somehow" might be re-written "perhaps someone else came across a rock and remembers it." There are too many rocks you have to at least tell us what road you are on and which way you were looking.

--
$you = new YOU;
honk() if $you->love(perl)