You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Andrew Merton (subscriptions)" <am...@gmail.com> on 2012/01/10 09:29:28 UTC
Re: Problem with long http request generation time - process restarting
On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
>> Thanks for the responses :)
>>
>> However - I just read another thread somewhere that made me think of
>> looking in the Event log.
>>
>> It appears that the culprit is Oracle - there are errors
>> naming OraOCIEI11.dll as the "Faulting Module name".
> That's very interesting. Windows Event Viewer is a good place to
> look (I keep forgetting about it as I'm used to /var/log/messages in
> Unix/Linux and similar environments).
Well. It turns out that in this case the event log was actually a red
herring. By creating another Apache instance (to avoid breaking the
"production" server :)) and stripping out all references to Oracle, DBI,
DBD etc from both httpd.conf and the Perl, I have determined that the
problem has nothing to do with Oracle.
After doing that, I was getting exception code 0xC00000FD (Stack
overflow) in Classify.dll (Params::Classify?) so I tried setting the
ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is
unknown according to the Event log.
I think I'm going mad.
Is there a way to make Apache/mod_perl (on Windows 7) give me a stack
dump when the child process exits? Al I get in the log is the "Parent:
child process exited ..." message, which is not very helpful. I have
downloaded the -symbols.zip files from ActiveState and installed them in
the proper directories (alongside their .dlls), but then realised that
I'm not getting the equivalent of a core dump file to analyze. The
Event log points to a directory containing only a text file (*.wer)
which doesn't have anything useful AFAICS...
Andrew
Re: Problem with long http request generation time - process restarting
Posted by Andrew Merton <am...@gmail.com>.
Thanks Hans - that fits with what I'm seeing (including no connection with
Oracle).
I had previously discovered that including DateTime in a handler made it
crash at start-up (actually using DateTime wasn't actually necessary) , but
didn't make the connection between that and Params::Classify partly because
this crash only occurs under certain circumstances. When I later
reintroduced DateTime it didn't seem to crash any more, so I never thought
it would be causing this one. Oh well, live and learn...
Thanks for the response...
Andrew
On Sun, Jan 29, 2012 at 11:52 AM, Hans Scharler <hs...@gmail.com> wrote:
> The Classify.dll issue gave me much trouble to figure out. In my instance,
> the issue has nothing to do with the database or Oracle.
>
> Here's what I found:
>
> Updating DateTime to version 0.72 includes Params::Classify as a
> dependency.
>
> http://search.cpan.org/~drolsky/DateTime-0.72/
>
> Also, DateTime-TimeZone version 1.40 also includes Params::Classify.
>
> When Classify.dll gets onto a Windows installation of mod_perl, Apache
> will crash/restart often. Regular Perl is fine.
>
> The latest DateTime and DateTime-TimeZone modules that work with mod_perl
> are DateTime 0.70 and DateTime-TimeZone 1.34.
>
> I spend a few days troubleshooting Classify.dll and the only way I could
> get it to work was to remove it and use older versions of DateTime.
>
> I hope this helps you out.
>
> Cheers,
> Hans
>
>
>
> On Fri, Jan 27, 2012 at 5:44 PM, Perrin Harkins <pe...@elem.com> wrote:
>
>> Sorry, just a clumsy cell phone touch.
>>
>> - Perrin
>> On Jan 27, 2012 5:42 PM, "Perrin Harkins" <pe...@elem.com> wrote:
>>
>>> - Perrin
>>> On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <
>>> amerton.signup@gmail.com> wrote:
>>>
>>>> On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
>>>>
>>>> Thanks for the responses :)
>>>>
>>>> However - I just read another thread somewhere that made me think of
>>>> looking in the Event log.
>>>>
>>>> It appears that the culprit is Oracle - there are errors
>>>> naming OraOCIEI11.dll as the "Faulting Module name".
>>>>
>>>> That's very interesting. Windows Event Viewer is a good place to
>>>> look (I keep forgetting about it as I'm used to /var/log/messages in
>>>> Unix/Linux and similar environments).
>>>>
>>>> Well. It turns out that in this case the event log was actually a red
>>>> herring. By creating another Apache instance (to avoid breaking the
>>>> "production" server :)) and stripping out all references to Oracle, DBI,
>>>> DBD etc from both httpd.conf and the Perl, I have determined that the
>>>> problem has nothing to do with Oracle.
>>>>
>>>> After doing that, I was getting exception code 0xC00000FD (Stack
>>>> overflow) in Classify.dll (Params::Classify?) so I tried setting the
>>>> ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is unknown
>>>> according to the Event log.
>>>>
>>>> I think I'm going mad.
>>>>
>>>> Is there a way to make Apache/mod_perl (on Windows 7) give me a stack
>>>> dump when the child process exits? Al I get in the log is the "Parent:
>>>> child process exited ..." message, which is not very helpful. I have
>>>> downloaded the -symbols.zip files from ActiveState and installed them in
>>>> the proper directories (alongside their .dlls), but then realised that I'm
>>>> not getting the equivalent of a core dump file to analyze. The Event log
>>>> points to a directory containing only a text file (*.wer) which doesn't
>>>> have anything useful AFAICS...
>>>>
>>>> Andrew
>>>>
>>>
>
Re: Problem with long http request generation time - process restarting
Posted by Hans Scharler <hs...@gmail.com>.
The Classify.dll issue gave me much trouble to figure out. In my instance,
the issue has nothing to do with the database or Oracle.
Here's what I found:
Updating DateTime to version 0.72 includes Params::Classify as a dependency.
http://search.cpan.org/~drolsky/DateTime-0.72/
Also, DateTime-TimeZone version 1.40 also includes Params::Classify.
When Classify.dll gets onto a Windows installation of mod_perl, Apache will
crash/restart often. Regular Perl is fine.
The latest DateTime and DateTime-TimeZone modules that work with mod_perl
are DateTime 0.70 and DateTime-TimeZone 1.34.
I spend a few days troubleshooting Classify.dll and the only way I could
get it to work was to remove it and use older versions of DateTime.
I hope this helps you out.
Cheers,
Hans
On Fri, Jan 27, 2012 at 5:44 PM, Perrin Harkins <pe...@elem.com> wrote:
> Sorry, just a clumsy cell phone touch.
>
> - Perrin
> On Jan 27, 2012 5:42 PM, "Perrin Harkins" <pe...@elem.com> wrote:
>
>> - Perrin
>> On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <
>> amerton.signup@gmail.com> wrote:
>>
>>> On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
>>>
>>> Thanks for the responses :)
>>>
>>> However - I just read another thread somewhere that made me think of
>>> looking in the Event log.
>>>
>>> It appears that the culprit is Oracle - there are errors
>>> naming OraOCIEI11.dll as the "Faulting Module name".
>>>
>>> That's very interesting. Windows Event Viewer is a good place to
>>> look (I keep forgetting about it as I'm used to /var/log/messages in
>>> Unix/Linux and similar environments).
>>>
>>> Well. It turns out that in this case the event log was actually a red
>>> herring. By creating another Apache instance (to avoid breaking the
>>> "production" server :)) and stripping out all references to Oracle, DBI,
>>> DBD etc from both httpd.conf and the Perl, I have determined that the
>>> problem has nothing to do with Oracle.
>>>
>>> After doing that, I was getting exception code 0xC00000FD (Stack
>>> overflow) in Classify.dll (Params::Classify?) so I tried setting the
>>> ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is unknown
>>> according to the Event log.
>>>
>>> I think I'm going mad.
>>>
>>> Is there a way to make Apache/mod_perl (on Windows 7) give me a stack
>>> dump when the child process exits? Al I get in the log is the "Parent:
>>> child process exited ..." message, which is not very helpful. I have
>>> downloaded the -symbols.zip files from ActiveState and installed them in
>>> the proper directories (alongside their .dlls), but then realised that I'm
>>> not getting the equivalent of a core dump file to analyze. The Event log
>>> points to a directory containing only a text file (*.wer) which doesn't
>>> have anything useful AFAICS...
>>>
>>> Andrew
>>>
>>
Re: Problem with long http request generation time - process restarting
Posted by Perrin Harkins <pe...@elem.com>.
Sorry, just a clumsy cell phone touch.
- Perrin
On Jan 27, 2012 5:42 PM, "Perrin Harkins" <pe...@elem.com> wrote:
> - Perrin
> On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <
> amerton.signup@gmail.com> wrote:
>
>> On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
>>
>> Thanks for the responses :)
>>
>> However - I just read another thread somewhere that made me think of
>> looking in the Event log.
>>
>> It appears that the culprit is Oracle - there are errors
>> naming OraOCIEI11.dll as the "Faulting Module name".
>>
>>
>> That's very interesting. Windows Event Viewer is a good place to
>> look (I keep forgetting about it as I'm used to /var/log/messages in
>> Unix/Linux and similar environments).
>>
>> Well. It turns out that in this case the event log was actually a red
>> herring. By creating another Apache instance (to avoid breaking the
>> "production" server :)) and stripping out all references to Oracle, DBI,
>> DBD etc from both httpd.conf and the Perl, I have determined that the
>> problem has nothing to do with Oracle.
>>
>> After doing that, I was getting exception code 0xC00000FD (Stack
>> overflow) in Classify.dll (Params::Classify?) so I tried setting the
>> ThreadStackSize to 2MB, and now I get 0xC0000005 and the module is unknown
>> according to the Event log.
>>
>> I think I'm going mad.
>>
>> Is there a way to make Apache/mod_perl (on Windows 7) give me a stack
>> dump when the child process exits? Al I get in the log is the "Parent:
>> child process exited ..." message, which is not very helpful. I have
>> downloaded the -symbols.zip files from ActiveState and installed them in
>> the proper directories (alongside their .dlls), but then realised that I'm
>> not getting the equivalent of a core dump file to analyze. The Event log
>> points to a directory containing only a text file (*.wer) which doesn't
>> have anything useful AFAICS...
>>
>> Andrew
>>
>
Re: Problem with long http request generation time - process restarting
Posted by Perrin Harkins <pe...@elem.com>.
- Perrin
On Jan 13, 2012 6:47 PM, "Andrew Merton (subscriptions)" <
amerton.signup@gmail.com> wrote:
> On 17/12/2011 7:20 a.m., Randolf Richardson wrote:
>
> Thanks for the responses :)
>
> However - I just read another thread somewhere that made me think of
> looking in the Event log.
>
> It appears that the culprit is Oracle - there are errors
> naming OraOCIEI11.dll as the "Faulting Module name".
>
>
> That's very interesting. Windows Event Viewer is a good place to
> look (I keep forgetting about it as I'm used to /var/log/messages in
> Unix/Linux and similar environments).
>
> Well. It turns out that in this case the event log was actually a red
> herring. By creating another Apache instance (to avoid breaking the
> "production" server :)) and stripping out all references to Oracle, DBI,
> DBD etc from both httpd.conf and the Perl, I have determined that the
> problem has nothing to do with Oracle.
>
> After doing that, I was getting exception code 0xC00000FD (Stack overflow)
> in Classify.dll (Params::Classify?) so I tried setting the ThreadStackSize
> to 2MB, and now I get 0xC0000005 and the module is unknown according to the
> Event log.
>
> I think I'm going mad.
>
> Is there a way to make Apache/mod_perl (on Windows 7) give me a stack dump
> when the child process exits? Al I get in the log is the "Parent: child
> process exited ..." message, which is not very helpful. I have downloaded
> the -symbols.zip files from ActiveState and installed them in the proper
> directories (alongside their .dlls), but then realised that I'm not getting
> the equivalent of a core dump file to analyze. The Event log points to a
> directory containing only a text file (*.wer) which doesn't have anything
> useful AFAICS...
>
> Andrew
>