Re^4: Help requested to find the cause of an "uninitialized value" message

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

Comment on Re^4: Help requested to find the cause of an "uninitialized value" message Select or Download Code

Replies are listed 'Best First'.
Re^5: Help requested to find the cause of an "uninitialized value" message by Marshall (Canon) on Jan 29, 2022 at 17:58 UTC
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]

Replies are listed 'Best First'.

Re^5: Help requested to find the cause of an "uninitialized value" message
by Marshall (Canon) on Jan 29, 2022 at 17:58 UTC

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]