in reply to forking memory problem
Dave
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: forking memory problem
by pg (Canon) on Nov 28, 2003 at 05:23 UTC | |
davido, I don't think it is a runaway loop. If it is a run away loop, he should get error "fork didn't work: Resource temporarily unavailable", as sacco only goes to waitpid after all the fork is done. This has to be a Perl bug. Whatever how bad or how good sacco's code is, it is not direclty managing memory access. | [reply] |
by davido (Cardinal) on Nov 28, 2003 at 05:44 UTC | |
If it is a run away loop, he should get error "fork didn't work: Resource temporarily unavailable" I'm not going to venture a guess at this point. The error message you suggested doesn't show up in perldiag. And here is the message the original post suggested he's seeing:
I get an error "The instruction at ####### referenced memory at #######. The memory could not be read." That message also doesn't appear in perldiag. perlbug states: Check in perldiag to see what any Perl error message(s) mean. If message isn't in perldiag, it probably isn't generated by Perl. Consult your operating system documentation instead. Since the OP's error message isn't listed in perldiag, I can only assume that it's either generated by a module, or by the operating system. We haven't been told what modules are in use. The original post also doesn't mention what operating system the code is running on. So we know we're not seeing a Perl error (assuming the OP gave us the correct error message), but that's about all we know for sure. The code snippet provided leaves open the possibility of a runaway loop. But it also leaves a lot of other possibilities that need clarification. No more guesses from me until we get more details. It's probably way premature to assume a Perl bug though. ;)
Dave "If I had my life to live over again, I'd be a plumber." -- Albert Einstein | [reply] |
by tilly (Archbishop) on Dec 01, 2003 at 00:50 UTC | |
Please remember that the messages in perldiag can change a lot from one version of Perl to the next. Looking in perldiag is one occasion where you absolutely want to be sure that you have the right version of perldiag for the right version of Perl, because if you have it wrong, there is a good chance that it isn't there. | [reply] |
by pg (Canon) on Nov 28, 2003 at 06:06 UTC | |
"If message isn't in perldiag, it probably isn't generated by Perl. Consult your operating system documentation instead." Of course it is not a Perl generated message, Perl already crashed upon memory access violation. This is a message generated by operating system, but it is caused by Perl. "The code snippet provided leaves open the possibility of a runaway loop." I actually never said that possibility is exculded. What I said is that, run away loop is irrelevent here (The error message does not indicate this). If his code has a run away loop, with the run away loop alone, sacco's code will quickly use up resource and can no longer fork (so his fork will fail, and get the message I mentioned. I saw this message before on both unix and win32 when I forgot to waitpid and kept forking.) On the other hand, even if it is caused by run away loop, it is still a Perl bug. Perl shall not crash on run away loop. | [reply] |
by sacco (Beadle) on Nov 28, 2003 at 16:52 UTC | |
I tried to copy about 700 files with 5 child processes and it dies with the error message at about 97% completion. I even tried to copy less files (200) - same thing. Here's the whole code, if it helps:
| [reply] [d/l] |
|
Re: Re: forking memory problem
by sacco (Beadle) on Nov 28, 2003 at 03:39 UTC | |
i.e. 5 | [reply] |