Comments on: Chasing a Very Elusive Warning

By: Tim Bunce

Tim Bunce — Wed, 17 Aug 2011 21:26:48 +0000

I agree with Dave. The “in …” part of the warning refers to the last opcode perl executed.

I wrote a blog post on how I tackle this a few years ago: http://blog.timbunce.org/2008/05/08/finding-the-cause-of-inexplicable-warnings-in-xs-code/

By: Ed Avis

Ed Avis — Wed, 17 Aug 2011 11:06:46 +0000

I have found the tool ‘delta’ to be useful in these situations. You first need to create a single-file test case that produces the warning, probably by concatenating all the source files (including the LibXML code) into one big program – replacing ‘use’ and ‘require’ statements with the contents of the files they load. Then you write a test harness which runs the program and checks for the error message, though without requiring a particular line number. You can now use ‘delta’ to generate a minimal test case – the shortest Perl program which produces the error.

The only trouble is that ‘Use of uninitialized value in subroutine entry’ might crop up anyway when running one of the minimized test files; it’s not a bug in perl itself, so simply producing the shortest source file that gives this warning may not be helpful.

Nonetheless, making a test case of a single huge file and then whittling it down by hand can be a good way to find what’s going on, if you have a few hours to spare.

By: Uwe

Uwe — Wed, 17 Aug 2011 09:57:23 +0000

I use Carp::Always in such cases to get a stacktrace and see which line of my code is causing this warning.

By: Joel

Joel — Wed, 17 Aug 2011 05:15:40 +0000

I know you certainly have looked at perldiag, but if not here is the relevant warning:

Use of uninitialized value%s
(W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a “” or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables.
To help you figure out what was undefined, perl will try to tell you the name of the variable (if any) that was undefined. In some cases it cannot do this, so it also tells you what operation you used the undefined value in. Note, however, that perl optimizes your program and the operation displayed in the warning may not necessarily appear literally in your program. For example, “that $foo” is usually optimized into “that ” . $foo , and the warning will refer to the concatenation (.) operator, even though there is no . in your program.

You can of course call `no warnings ‘uninititialized’` somewhere just above the offending call, and/or check to see that the subroutine args are in fact what you thing they are.

I feel silly mentioning all this since you know all of it, but sometimes I lose the trees for the forest and need someone to remind me about them. Good luck, I hope you find it!

By: Mike Doherty

Mike Doherty — Wed, 17 Aug 2011 02:56:14 +0000

I’m having a similar issue, reported here: https://rt.cpan.org/Ticket/Display.html?id=70253

If you gain any great insight, I’d love to be taught how to track down this sort of thing.

By: hdp

hdp — Wed, 17 Aug 2011 02:39:06 +0000

make test sets $^W, prove does not, and XML/LibXML.pm does not ‘use warnings’.

By: Dave Rolsky

Dave Rolsky — Wed, 17 Aug 2011 01:02:46 +0000

In my experience, this warning comes when you pass an undef value to a subroutine implemented in XS that is not explicitly checking for undef internally. I’d start looking into any XS code called at that particular line.