in reply to Re^2: Help requested to find the cause of an "uninitialized value" message
in thread Help requested to find the cause of an "uninitialized value" message

And therefore the pattern match will match: <Dumped-data-from-%INFO>:DONE::MSG:<Dumped-data-from-another-%INFO>

That's definitely something I would recommend you look into. Another possibility is that $collected is something like ":MSG:stuff:DONE::MSG:stuff" when you do $collected = "", breaking the stream, or that :MSG: and :DONE: are a part of the Dumper output. Although I still don't recommend using Data::Dumper and especially eval for this, here are some steps you can take. First, make your start and end markers a little more robust: I think for example Data::Dumper wouldn't output a "\0" when its Useqq option is turned on (and you can even validate this by checking the string before you send it). Second, use a s/// regex to remove output you get from $collected instead of completely clearing it, and/or validate the format of $collected before you do.

If you still have trouble, it would be great if you could combine the tidbits of code you've provided into an SSCCE that reproduces the issue, then I'm sure we can get it debugged pretty quick.

Update: A few minor additions to the above.

Replies are listed 'Best First'.
Re^4: Help requested to find the cause of an "uninitialized value" message
by andyok (Novice) on Jan 25, 2022 at 13:52 UTC
    Thank you for your comments.
    I have created a small test-case which at least causes the same error-message to be generated.
    (I appreciate that many causes may generate the same error-message).

    In my small test-case, if I have a "corrupted" $dumped that is passed to eval, then I get the same error-message.
    And by corrupted, I mean:
    • that the collection/appending of snippets of string from read() onto $collected
    • followed by the extraction of one framed message
    • followed by the complete nulling of $collected without testing to see if there is a residue of text that should be preserved
    could result in a ill-formated string that gets passed to eval.

    And, in such an instance, I note that the result of the eval results in a %info that is empty.

    (It never crossed my mind to consider that %info = %{ eval $dumper}</code} would result in a null %info.)
    So this then becomes another possible trigger for break-pointing or printing out extra information at/around the failure point.

    Thank you for your thoughts and time.
    Andrew
[reply]
[d/l]
[select]
      I checked back in after a couple of days to see how you are making out?

      In my suggestions at this node, I am assuming that the autoflush would have the same effect as manually flushing after your child's print statement. Further assumed is that this file event notification does work and means that the pipe is ready for reading. If the pipe has any data in it, then all of the data for a single msg should be coming forthwith and certainly fast enough to have no impact on GUI performance.

      If both of those are true, then my suggested blocking read until DONE seen should work well and you don't need your read() statement. There should never be any "garbage" before the start of the frame, e.g. "MSG". Stopping reading after seeing DONE should leave the input pipe completely empty. Things are more complicated if 2 msgs could be "back to back". But since they are only sent once per 10 seconds, I see no problem. Of concern with "back to back" messages would be timing issues with "re-enabling" the file even notification mechanism - not sure how that would work.

      A good assumption for these pipes is that they are lossless. Probability of corruption is on the order of a memory RAM error (which nowadays is very low).

[reply]

In Section Seekers of Perl Wisdom