Re^2: Error ... at (eval 75) line 7974.

The main problem is finding the particular call to the string eval that is causing the problem

If you run the script under the debugger (perl -d), it'll give the location of the relevant eval in the error message; locating the offending dereference is then just a matter of arithmetic.

It feels like there should be an even more convenient way to do this -- some combination of command-line options that would produce the more informative error message without going through the interactive debugger -- but I personally don't know of one.

Comment on Re^2: Error ... at (eval 75) line 7974.

Replies are listed 'Best First'.
Re^3: Error ... at (eval 75) line 7974. by syphilis (Archbishop) on Apr 13, 2009 at 12:45 UTC
It feels like there should be an even more convenient way to do this Too bloody right it does ... so far it seems that "at (eval 75) line 7974" is, in effect, just another way of saying "somewhere or other". There is no string eval in the script itself, or in the modules it directly loads - though there could be a string eval in one of the modules that ultimately gets loaded. (I'm looking at you, Parse::RecDescent.) I have established that the problem goes away if I replace Parse-RecDescent-1.96.0 with Parse-RecDescent-1.94. I get the feeling that it's just a matter of explicitly assigning `[]` to a hashref key if that key is undef ... in which case it's just a matter of working out which key it is. Maybe it's time to try a time a dump of the hash reference. Btw, I don't doubt that my problem would be made simpler if I was debugger-savvy, or Carp-savvy (as bloodnok and Anonymous Monk suggested). I did have a bit of a play with Carp, but only got a heap of Parse::RecDescent messages that didn't mean much. Cheers, Rob	[reply] [d/l]
Re^4: Error ... at (eval 75) line 7974. by Bloodnok (Vicar) on Apr 13, 2009 at 13:22 UTC
Yep, you're right, t'was a bad call for which I apologise for misleading you - Carp is used in place of [perlfunc://die] i.e. when you're in control of when (and indeed where) the script dies. In your case that's completely moot since you don't know where the script is dying!! Try `use diagnostics;` in your script, that should print a stack trace + a load of diagnostic (hence it's name:-) information when you hit the error. A user level that continues to overstate my experience :-))	[reply] [d/l]