Skip Menu |

This queue is for tickets about the Parse-RecDescent CPAN distribution.

Report information
The Basics
Id: 68809
Status: resolved
Priority: 0/
Queue: Parse-RecDescent

People
Owner: Nobody in particular
Requestors: NINUZZO [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.965001
Fixed in: (no value)



Subject: Unclosed filehandles cause trouble when forking
Hi, I have a CGI that uses Parse::RecDescent and then forks, closing STDOUT and STDERR in the child, while the parent exits right way. Well, the parent becomes a zombie and Apache waits for the child to terminate before returning any output to the browser. This was a nasty bug and wasn't easy to find out that Parse::RecDescent is the culprit :) I have found a workaround: along with STDOUT and STDERR I also close these three files belonging to Parse::RecDescent in the child code: close(Parse::RecDescent::TRACECONTEXT); close(Parse::RecDescent::ERROR); close(Parse::RecDescent::TRACE); This works for me, although it is not very But is there a better way to close these files? Could I avoid creating them in the first place? I have noticed that TRACECONTEXT is just a duplicate for STDERR: open (TRACECONTEXT, ">&STDERR"); Why isn't STDERR used directly? A module should not left any files opened or have a finalize method/destructor to close them, but I do not know whether this is doable or not in Parse::RecDescent. Thanks for your support. Antonio Bonifati http://ninuzzo.freehostia.com
Subject: Re: [rt.cpan.org #68809] Unclosed filehandles cause trouble when forking
Date: Mon, 27 Jun 2011 08:13:55 +1000
To: bug-Parse-RecDescent [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
Hi Antonio, You asked: Show quoted text
> I have noticed that TRACECONTEXT is just a duplicate for STDERR: > Why isn't STDERR used directly?
Because you can only have one 'format' statement per filehandle, so if you need different formats all feeding the same output stream, you need to duplicate the filehandle under a new name. However, it also seems to work if you merely alias the new filehandles, and aliased filehandles might not cause the process to zombify, so long as the originals were closed. I can't try that, since I don't have your setup, but you could try it by replacing the following three lines in RecDescent.pm: open (ERROR, ">&STDERR"); ... open (TRACE, ">&STDERR"); ... open (TRACECONTEXT, ">&STDERR"); with: open (ERROR, ">&=STDERR"); ... open (TRACE, ">&=STDERR"); ... open (TRACECONTEXT, ">&=STDERR"); respectively. If that doesn't work, you could also try adding the following to the module source: END { close *ERROR; close *TRACE; close *TRACECONTEXT; } The problem is, I'm not sure whether Apache would run the END block correctly. Anyway, if either of those work (with your workaround commented out, of course ;-) please let me know and I'll add them to the module for the next release. All the best, Damian
RT-Send-CC: m.orr [...] daxtra.com
Hi Damian, I've just tried both your proposed fixes on our setup and unfortunately Apache still waits for all children to terminate, so nothing doing :( It doesn't seem to be an easy fix on your module side, whilst in my child process code (just after forking) I've sorted out by adding: close(Parse::RecDescent::TRACECONTEXT); close(Parse::RecDescent::ERROR); close(Parse::RecDescent::TRACE); aside from: close(STDOUT); close(STDERR); If you have another idea, let me know and we will try it out. Anyway this kludge works for us and we are quite happy with it :) Strangely enough, we have a Fedora Core 5 machine where this isn't an issue, whilst in every other setup we have tried, including latest stable versions of Apache and mod_perl, we are experiencing the same problem. That Fedora machine runs httpd-2.2.0-5.1.2 and mod_perl-2.0.2- 5.1. Thank you for your effort.
Subject: Re: [rt.cpan.org #68809] Unclosed filehandles cause trouble when forking
Date: Thu, 7 Jul 2011 08:17:30 +1000
To: bug-Parse-RecDescent [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
Hi Antonio, Show quoted text
> I've just tried both your proposed fixes on our setup and unfortunately > Apache still waits for all children to terminate, so nothing doing :(
I've thought of another possibility, but it will take a little time to code (and I'm desperately short of time just how, it being two weeks before the start of my summer speaking tour). When I get the chance (probably when I'm actually *on* my summer speaking tour), I'll try out this new approach and send another beta to you. Damian
Subject: Re: [rt.cpan.org #68809] Unclosed filehandles cause trouble when forking
Date: Tue, 11 Oct 2011 12:13:55 +1100
To: bug-Parse-RecDescent [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
Hi Antonio, I finally got round to implementing my new approach to error messages and tracing. This approach uses no extra filehandles at all (everything goes to the original STDERR), so it should solve your original problem. If you're still interested, please give it a try and let me know how if it works for you. All the best, Damian

Message body is not shown because sender requested not to inline it.

I believe that the new trace/error output code that writes everything to STDERR resolves this issue. If not, please reopen the ticket. Thank you for the bug report!