perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <Steve...@planit.com>
Subject RE: [RELEASE CANDIDATE] mod_perl-1.31 RC4
Date Tue, 22 Apr 2008 11:40:32 GMT
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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message