Steve Hay wrote:
[...]
> Thus, the end of my mod_perl build goes like this:
>
> msdev src\modules\win32\mod_perl.dsp /MAKE "mod_perl - Win32
> Release" /USEENV
> --------------------Configuration: mod_perl - Win32
> Release--------------------
> Compiling...
> Apache.c
> Connection.c
> Constants.c
> File.c
> Log.c
> ModuleConfig.c
> ModuleConfig.xs(72) : warning C4715: 'vector_from_sv' : not all
> control paths return a value
> mod_perl.c
> mod_perl_opmask.c
> perl_config.c
> perl_util.c
> perlio.c
> perlxsi.c
> Server.c
> Table.c
> URI.c
> Util.c
> Linking...
> Creating library Release/mod_perl.lib and object
> Release/mod_perl.exp
>
> mod_perl.so - 0 error(s), 1 warning(s)
>
> Notice the "Win32 Release" configuration there. So you need to rebuild
> mod_perl.so in debug mode after running the initial "nmake". You can
> do so by running the following command (from the top-level directory):
>
> msdev src\modules\win32\mod_perl.dsp /MAKE "mod_perl - Win32 Debug"
Oops! I missed the " /USEENV" off the end of that command-line. You need
that too, as per the original command-line shown above.
[...]
> PerlIOUnix_setfd() is calling PerlIOUnix_refcnt_inc(fd)
> with fd 0. Simply put a breakpoint on line 2548 in perlio.c and it
> crashes the first time it hits it. Stepping inside
> PerlIOUnix_refcnt_inc() I find that it reaches the line
>
> MUTEX_LOCK(&PL_perlio_mutex);
>
> (which is only present in the USE_ITHREADS case) and crashes there.
> PL_perlio_mutex itself is a valid struct, but all its members are 0 or
> 0x00000000. I don't know if that's normal.
>
> On Win32, MUTEX_LOCK(m) seems to be #defined as
> EnterCriticalSection(m) (in win32\win32thread.h, given that
> DONT_USE_CRITICAL_SECTION is never #defined anywhere). Hmm. The
> comment there says "Critical Sections used instead of mutexes:
> lightweight, but can't be communicated to child processes ...". I
> wonder if the other case in that #ifndef might be worth trying,
> although that wouldn't be the default build option so we shouldn't
> need to do that... Perhaps Jan can assist here?
I tried a build with DONT_USE_CRITICAL_SECTION defined, but it behaves
exactly the same except that the other #definition of MUTEX_LOCK(m) is
now used, namely:
# define MUTEX_LOCK(m) \
STMT_START { \
if (WaitForSingleObject(*(m),INFINITE) == WAIT_FAILED) \
Perl_croak_nocontext("panic: MUTEX_LOCK"); \
} STMT_END
so I get a "panic: MUTEX_LOCK" error instead of the crash! Or at least,
that's the string shown in "pat" in Perl_croak_nocontext() by the
debugger, but the console output actually says:
parse: Bad file descriptor
I'm not sure if that's any kind of clue.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
