So digging a little deeper (and through the magic of trial and error), the
offending module seems to be Mail::Field.
It has a bunch of code to dynamically load perl classes for various types of
fields (AddrList, Date, Content-Type, etc), and this code seems to do
something that makes modperl (or apache) very unhappy.
Basically, it seems to blow through the INC list, looking for a directory
that matches Mail::Field. When it finds such a directory, it blows
recursively through it, using "require" on every file it finds.
Somewhere, this seems to be causing apale or modperl some unhappiness.
Any other clues or pointers? I'm half tempted at this point to rewrite
things as a CGI rather than a module, because MIME::Parser seems to work
from a CGI.
-jse
> From: "John S. Evans" <[EMAIL PROTECTED]>
> Date: Fri, 14 Apr 2000 16:02:20 -0700
> To: modperl <[EMAIL PROTECTED]>
> Cc: Stas Bekman <[EMAIL PROTECTED]>
> Subject: Re: modperl and MIME::Parser?
>
> I ran struss, but I'm not sure how useful the put is. I've enclosed it, if
> anyone has time to take a look...
>
> It does look like there might have been some problem loading some of the
> modules (Mail/Field/addrlist.pm), but I can't find anyone who actually uses
> that module. But typically when Apache can't load a module, it prints an
> error message for me. In this case, the apache log gets NO entries it in,
> but the process is still running.
>
> Unfortunately, I don't have apache compiled with symbols (there were
> stripped), but here is the stack trace while Apache is "hung":
>
> #0 0xff216f8c in _read () from /usr/lib/libc.so.1
> #1 0xff208094 in _filbuf () from /usr/lib/libc.so.1
> #2 0x11a900 in Perl_sv_gets ()
> #3 0xe02a0 in Perl_filter_read ()
> #4 0xee004 in Perl_pmflag ()
> #5 0xe37a8 in Perl_yylex ()
> #6 0xefa90 in Perl_yyparse ()
> #7 0x135f08 in Perl_sv_compile_2op ()
> #8 0x136ce0 in Perl_pp_require ()
> #9 0x14d508 in Perl_runops_standard ()
> #10 0xd5b14 in perl_eval_sv ()
> #11 0xd5f04 in perl_require_pv ()
> #12 0x39be0 in perl_reload_inc ()
> #13 0x310f0 in perl_restart ()
> #14 0x317b4 in perl_startup ()
> #15 0x31524 in perl_module_init ()
> #16 0x77188 in ap_init_modules ()
> #17 0x8500c in ap_child_terminate ()
> #18 0x85d14 in main ()
>
> It looks like it may be blocked in a read somewhere. Very strange.
>
> -jse
>
>
>> From: Stas Bekman <[EMAIL PROTECTED]>
>> Date: Fri, 14 Apr 2000 23:20:17 +0300 (IDT)
>> To: "John S. Evans" <[EMAIL PROTECTED]>
>> Cc: modperl <[EMAIL PROTECTED]>
>> Subject: Re: modperl and MIME::Parser?
>>
>> On Fri, 14 Apr 2000, John S. Evans wrote:
>>
>>> So I'm trying to work around my problems with Apache::Request by parsing the
>>> request myself. This way I can work with only a single open file at a time.
>>>
>>> But now I have a new problem. In my content handler, if I add "use
>>> MIME::Parser;" to the top of my file, apache won't start - it seems to hang
>>> during the startup phase. My module never gets initialized, and apache
>>> never prints "[Fri Apr 14 12:29:14 2000] [notice] Apache/1.3.9 (Unix)
>>> mod_perl/1.21 configured -- resuming normal operations".
>>>
>>> I don't even call any functions in the module yet, just "use" it. If I take
>>> out the "use" statement, apache (and my module) load just fine.
>>>
>>> Can you think of anything that would cause the MIME::Parser module to
>>> disagree with modperl? I'm just about to start reaming through the
>>> MIME::Parser source code looking for stuff that gets initialized at
>>> module-load time.
>>
>> I've no idea about the cause, but why don't you start the server under
>> strace (or truss) and see where it hangs. If you don't figure out by
>> yourself send the trace to the list (the relevant snippet if you know
>> what's relevant).
>>
>> See:
>> http://perl.apache.org/guide/debug.html#Determination_of_the_reason
>> http://perl.apache.org/guide/debug.html#Debug_Tracing
>>
>> ______________________________________________________________________
>> Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
>> http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
>> mailto:[EMAIL PROTECTED] | http://perl.org http://stason.org/TULARC/
>> http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
>> ----------------------------------------------------------------------
>>
>>
>
>
