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

The main problem is finding the particular call to the string eval that is causing the problem. What I do for these situations is:

use grep (or your code editors search facility) to find all of the calls to eval
insert print STDERR "before eval: <$sEval>\n" Although in this case you might want to print out only a substring rather than the whole string for evaluation.
If you don't mind a being a bit wordier, instead of the above, you can insert the following instead print STDERR "before eval \@ line " . __LINE__ . " of file " . __FILE__ . ": <$sEval>\n"
insert print STDERR "after eval\n"; after each eval.
Watch what happens

That should at least help you isolate the particular eval that is causing the problem. However, your real issue is a 7000 line file being eval'd at once. Once you know what string is being eval'd, I would recommend that you put the code in a file and test it running as a normally compiled script.

7000+ lines is awfully long for any script or module, even a test script. I usually try to keep them under 1000 lines and no more than 3000 in really unusual circumstances. You might want to think about how you can trim that down by

moving repetitive code into subroutines
data into support files
splitting up the code into separate more focused modules (i.e. test framework modules)

Best, beth

Comment on Re: Error ... at (eval 75) line 7974. Select or Download Code

Replies are listed 'Best First'.
Re^2: Error ... at (eval 75) line 7974. by Porculus (Hermit) on Apr 13, 2009 at 11:31 UTC
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.	[reply]
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]