views:

119

answers:

2

I have have a mod_perl program that implements its own handler function (i.e. it's not using Apache::Registry).

I have a parser module written using Parse::RecDescent.

I have been successfully using the parser module in another similar mod_perl program for months with no issue.

Simply "use"ing the parser module in the my new mod_perl program (i.e. no references to functions in the module) causes the Apache server to spawn child processes until it hits it's max limit. Commenting out the "use" statement solves the problem (but leaves me without the use of the parser, obviously).

I suspect that the inclusion of the library is doing something that causes the Apache lifecycle to hang before it ends. I believe this is happening after the logging phase since the response is sent and the log is updated.

Anyone have any clues for me? I'm at a loss.

--phil--

+1  A: 

I don't have an answer for you (personally, I use fastcgi...) but I can suggest an approach: attach strace, ltrace, gdb, etc. to the apache child process and see where its hanging. You may need to rebuild apache, mod_perl, and even perl with debug symbols to get reasonable output from gdb.

derobert
+1  A: 

So, I solved the problem, but don't understand why it worked. That leaves me slightly frustrated, but I'm grateful that the problem's gone.

Before I took derobert's suggestion and traced the process, I decided to move the library load to the mod_perl startup file and voila, problem solved.

Interesting that it took me a day of work to get to the point where I understood the problem enough to ask the question on SO and then once I got to that point, a simple thing solved it.

Phil Windley