in reply to Perl jumps to END logic after fileno (Win32)

Any assistance on what to look for would be very helpful.

If you have a problem with your car, do you show a picture of carpart to your mechanic? Cause you're really sure the hubcap ignition is the problem?

Yeah, hes like a mechanic, he knows what those things look like, what he needs is the actual malfunctioning machine

Translation, show a 5-20 line program that demonstrates the problem you want to solve, not some 8 lines of code you think are the problem

  • Comment on Re: Perl jumps to END logic after fileno (Win32)

Replies are listed 'Best First'.
Re^2: Perl jumps to END logic after fileno (Win32)
by dchidelf (Novice) on Aug 03, 2017 at 15:40 UTC

    I understand the difficulty in trying to troubleshoot a script with just the snippet. That is why I am here.

    The problem is that it is a little of 6000 lines of code with a dependency on an external application and only fails on a subset of the systems that run the tool. I can not actually get the code to fail on my system, but some of the user's systems fail pretty reliably and always on the fileno command.

    I was mostly looking for any insight anyone might have into what fileno does internally on a Win32 system that might cause the process termination, or even more generally if there is a way to tell what caused perl to jump to it's end blocks. I am just not familiar enough with the perl source code to follow fileno all the way down to it's actual implementation. And I was not aware if there were any status variables that might indicate what caused the jump to the end blocks.

    Perl is not executing the line of code after the fileno command, and it not throwing an exception. It simply jumps to the cleanup.

      This is what you need to do, assume the problem is with the code you wrote , because this is the beginning of debugging

      Copy your 6000 line program and start deleting lines, delete everything that doesn't trigger the problem, stop when you have it down to 20 lines max or you solved it

      If your 6000 lines of code are in any way organized it shouldn't take very long (15min-1hour)

      This is the only shortcut

      "Thinking" the problem lies in fileno and other pieces of code that have worked fine for a decade or two/three is naive -- if there was any merit to the idea you should be able to demonstrate it with ~20 lines of code