The mod_perl 1.31 release candidate 4 "Works with Perl 5.10" is ready.

It can be downloaded here:

http://www.apache.o­rg/~gozer/mp1/mod_pe­rl-1.31-rc4.tar.gz

MD5: ba12ce36c4c738bccfa­93ab646a6824c

SHA1: 2de6ce29f44505cfdca­34b7aa6499d961c72953­b

Please give it a spin in your favorite configuration and report

any problems. Especially needed against Perl-5.10.

The summary of what has changed since 1.30 are (from Changes):

Fix potential segfault when the environment contains

NULL values [Mike Schilli]

Fix static APACI build against newer apache-1.3.38+

[Gozer]

Fixed modules/regex.t test 4 on Win32

[Steve Hay]

Avoid possible segfault when PerlFreshRestart is On.

[Michael Rendell <michael@cs.mun.ca>]

Prevent segfault when running with perl >= 5.9.3

[Steve Hay]

Fix shared libary extensions on Win32 to be .dll not .so

[Nikolay Ananiev <ananiev@thegdb.com>]

Patch to mod_perl.dsp to remove /D _WINSOCK2API_ on Win32

for perl >= 5.8.6 [Steve Hay]

win32 vc6 FAIL

Sorry folks, still segfaulting. Backtrace below:

NTDLL! 7c918fea()

NTDLL! 7c90104b()

PerlIOUnix_open(int­erpreter * 0x009a4084, _PerlIO_funcs * 0x280cb548

_PerlIO_unix, PerlIO_list_s * 0x008230fc, long 0, const char *

0x280be174 `string', int 0, int 0, int 0, _PerlIO * * 0x00000000, int 0,

sv * * 0x00000000) line 2633

PerlIOBuf_open(inte­rpreter * 0x00000001, _PerlIO_funcs * 0x280cb708

_PerlIO_crlf, PerlIO_list_s * 0x008230fc, long 1, const char *

0x280be174 `string', int 0, int 0, int 0, _PerlIO * * 0x00000000, int 0,

sv * * 0x00000000) line 3692 + 27 bytes

PerlIO_openn(interp­reter * 0x009a4084, const char * 0x00000000, const

char * 0x280be174 `string', int 0, int 0, int 0, _PerlIO * * 0x00000000,

int 0, sv * * 0x00000000) line 1604 + 29 bytes

PerlIO_fdopen(int 0, const char * 0x280be174 `string') line 4995 + 22 bytes

PerlIO_stdstreams(i­nterpreter * 0x009a4084) line 1212

PerlIO_resolve_laye­rs(interpreter * 0x008230fc, const char * 0x00000000,

const char * 0x280b3b74 `string', int 1, sv * * 0x0012db64) line 1493 +

6 bytes

PerlIO_openn(interp­reter * 0x009a4084, const char * 0x00000000, const

char * 0x280b3b74 `string', int -1, int 0, int 0, _PerlIO * *

0x00000000, int 1, sv * * 0x0012db64) line 1575 + 20 bytes

PerlIO_open(const char * 0x0082316c, const char * 0x280b3b74 `string')

line 5004 + 21 bytes

S_open_script(inter­preter * 0x009a4084, const char * 0x0082316c, char 0,

sv * 0x009a6adc, int * 0x0012dbec, _PerlIO * * * 0x0012dbc4) line 3705 +

11 bytes

S_parse_body(interp­reter * 0xffffffff, char * * 0x00000000, void

(interpreter *)* 0x10026750 mod_perl_xs_init(in­terpreter *)) line 2056

perl_parse(interpre­ter * 0x009a4084, void (interpreter *)* 0x10026750

mod_perl_xs_init(in­terpreter *), int 4, char * * 0x0012dd2c, char * *

0x00000000) line 1651

perl_startup(server­_rec * 0x003f8e88, pool * 0x003f8e60) line 704 + 27

bytes

perl_cmd_require(cm­d_parms * 0x0012fe34, void * 0x003fa8f8, char *

0x003faa88) line 621 + 28 bytes

invoke_cmd(const command_struct * 0x10094c20, cmd_parms * 0x0012fe34,

void * 0x003fa8f8, const char * 0x0012de30) line 877 + 6 bytes

ap_handle_command(c­md_parms * 0x009a0108, void * 0x003f9a28, const char

* 0x0012de24) line 989

ap_srm_command_loop­(cmd_parms * 0x0012fe34, void * 0x003f9a28) line 1003

ap_process_resource­_config(server_rec * 0x003f8e88, char * 0x6ffae000

_ap_server_confname­, pool * 0x003f8e60, pool * 0x009a0058) line 1294 +

13 bytes

ap_read_config(pool­ * 0x003f8e60, pool * 0x009a0058, char * 0x6ffae000

_ap_server_confname­) line 1579

apache_main(int 6, char * * 0x00820110) line 7880 + 23 bytes

main(int 6, char * * 0x00820110) line 33 + 13 bytes

APACHE! mainCRTStartup + 227 bytes

KERNEL32! 7c816d4f()

Philippe M. Chiasson wrote:

Philippe M. Chiasson wrote:

win32 vc6 FAIL

Sorry folks, still segfaulting. Backtrace below:

On Wed, 2 Apr 2008, Issac Goldstand wrote:

[ ... ]

I also get this crash on startup on Win32:

perl-5.10.0 (ActivePerl 1002), Apache/1.3.34

However, given that

- it works with perl-5.8 (ActivePerl 822), where all tests pass

- most likely mod_perl-2 is used by most Windows users by now

- as Steve Hay found, it's something to do with the particular

compile-time settings used by ActivePerl

- this looks like it may take some time to track down

I again don't want to hold this up, unless there's a

strong objection, so take this as a +1; we could put a

note in the README saying that it doesn't work yet

on perl-5.10 ActivePerl.

On Wed, 2 Apr 2008, Issac Goldstand wrote:

[ ... ]

I also get this crash on startup on Win32:

perl-5.10.0 (ActivePerl 1002), Apache/1.3.34

However, given that

- it works with perl-5.8 (ActivePerl 822), where all tests pass

- most likely mod_perl-2 is used by most Windows users by now

- as Steve Hay found, it's something to do with the particular

compile-time settings used by ActivePerl

- this looks like it may take some time to track down

I again don't want to hold this up, unless there's a

strong objection, so take this as a +1; we could put a

note in the README saying that it doesn't work yet

on perl-5.10 ActivePerl.

The mod_perl 1.31 release candidate 4 "Works with Perl 5.10" is

ready. It can be downloaded here:

http://www.apache.o­rg/~gozer/mp1/mod_pe­rl-1.31-rc4.tar.gz

benedict# make

(cd ./apaci && PERL5LIB=/usr/local­/src/mod_perl-1.31-r­c4/lib: make)

make[1]: *** No rule to make target `libperl.so', needed by `lib'.

Stop.

make: *** [apxs_libperl] Error 2

This is on Mac OS X 10.5.2 with Perl 5.10 compiled like so:

sh Configure -des -Duseshrplib -Dperladmin=david@k­ineticode.com -Dcf_email=david@ki­neticode.com

make

make test

make install

*sigh*. I hope this is something simple.

On Apr 2, 2008, at 10:21, David E. Wheeler wrote:

Anyone have any ideas on this? I'm attempting to compile mod_perl as a

DSO outside of the Apache source tree using APXS. There must just be a

typo or something somewhere, yes? I mean, this worked for me before

So you end up with a Makefile that goes like

all: libperl.so (thank you Apache)

libperl.bundle: (thank you Perl/OSX)

Try with:

$> make PERL_DLEXT=so

On Apr 17, 2008, at 01:33, Philippe M. Chiasson wrote:

Yes, that works. I wonder why I didn't have to do it before? Is this

something that can be worked around?

The test suite didn't run for me, though. ­

This is an unexpected side effect of another fix, for static builds.

Correct me if I am wrong, but runnign the mp1 test suite as DSO isn't

really supported. Needs fixing, but that would take Apache::Test, not

something I am looking forward doing (I believe there is a patch on

that

somewhere in the archive from me, but it needed more work)

Philippe M. Chiasson wrote:

All tests OK using VC6 on WinXP with apache 1.3.39 and perl 5.10.0 built

without USE_MULTI, USE_ITHREADS or USE_IMP_SYS.

Crashes on startup with apache 1.3.41 and perl 5.10.0 built with default

options (i.e. with USE_MULTI, USE_ITHREADS or USE_IMP_SYS).

Steve Hay wrote:

Any chance to try and narrow it down a little bit more between these

3?

I've finally managed to reproduce this crash myself. I've had to bite

the bullet and get myself a Win32 VM I can actually build all this

stuff under.

Haven't managed to get a usefull debugging session running yet. Can't

seem to get VC6 to pick up/display debugging symbols. Any hits from

folks here with stronger win-foo than me ?

Thus, the end of my mod_perl build goes like this:

msdev src\modules\win32\m­od_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.li­b and object

Release/mod_perl.ex­p

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\m­od_perl.dsp /MAKE "mod_perl - Win32 Debug"

PerlIOUnix_setfd() is calling PerlIOUnix_refcnt_i­nc(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_i­nc() I find that it reaches the line

MUTEX_LOCK(&PL_perl­io_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

EnterCriticalSectio­n(m) (in win32\win32thread.h­, given that

DONT_USE_CRITICAL_S­ECTION 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?

Philippe M. Chiasson wrote:

I tried with USE_MULTI + USE_ITHREADS but no USE_IMP_SYS and it still

crashes, so it must be USE_ITHREADS that is doing it. (USE_MULTI is a

pre-requisite for USE_ITHREADS, so I can't try without that, and I've

a feeling that USE_MULTI on its own is useless and might not even

build.)

So basically, mp1 crashes with ithreaded builds of perl.