| Subcribe via RSS

Chasing a Very Elusive Warning

August 16th, 2011 Posted in Perl

I am getting a warning in one of my test suites for RPC-XML. I only get this warning when I run “make test“. I do not get the warning if I run the test directly with “perl -Mblib t/…“, or if I run it via prove. The test this occurs in is t/21_xml_libxml.t, which tests the XML::LibXML-based parser, and the warning I get is:

Use of uninitialized value in subroutine entry at .../site_perl/5.14.1/darwin-2level/XML/LibXML.pm line 843.

Because this is occurring within Perl itself, I cannot seem to get it to give me a stack-trace in place of the warning. My attempts to check for undefined values have not found any, yet I get the warning. Running in the debugger does not generate the warning.

Because my tests pass, I have confidence that this parser is fine, despite this only-in-test-harness warning. But the OCD side of me is going crazy over having this still show up when I run my tests locally (and yes, it shows up on all my platforms: Darwin, 64-bit Linux and 32-bit Linux). So, if anyone reading this can give me a helpful hint as to how I can get more/better diagnostic information on this, I would be truly grateful.

Tags: ,

7 Responses to “Chasing a Very Elusive Warning”

  1. Dave RolskyNo Gravatar Says:

    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.

  2. hdpNo Gravatar Says:

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

  3. Mike DohertyNo Gravatar Says:

    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.

  4. JoelNo Gravatar Says:

    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!

  5. UweNo Gravatar Says:

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

  6. Ed AvisNo Gravatar Says:

    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.

  7. Tim BunceNo Gravatar Says:

    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/

Leave a Reply