Randy Kobes <[EMAIL PROTECTED]> writes: >On Mon, 15 Sep 2003, Steve Hay wrote: > >> Jarkko Hietaniemi wrote: >> >> > http://www.iki.fi/jhi/[EMAIL PROTECTED] >> > http://www.iki.fi/jhi/[EMAIL PROTECTED] >> > >> >Regarding the *sigh* modperl *sigh*. What should we do with the >> >elusive modperl problems? >> > >> >My opinion is that we can't let them hold up 5.8.1 forever and I would >> >appreciate your opinions on the preferred length of "forever". >> > >> My preferred length of "forever" is "until we establish whether it is >> Perl's or mod_perl's fault that mp2+perl-5.8.1 doesn't currently even >> start up on Win32 (plus the time to fix it if it is Perl's fault" :-) >> >> Regarding the problem that I've got (which, unlike Stas' trouble, is >> completely reproduceable -- the server fails to start every time if mp2 >> is enabled), Randy Kobes has shed some light on this on the mod_perl dev >> list. My Apache server gets this far: >> >> main >> ap_run_pre_config >> modperl_hook_pre_config >> modperl_hash_seed_init >> Perl_safesysmalloc >> >> and then crashes trying to do: >> >> ptr = (Malloc_t)PerlMem_malloc(size?size:1); /* malloc(0) is >> NASTY on our system */ >> >> Notice the modperl_hash_seed_init() call there? Randy has found, and I >> can confirm, that Apache+mp2 is able to start up if we add >> >> #undef MP_NEED_HASH_SEED_FIXUP >> >> to the top of mp2's src/modules/perl/mod_perl.c. >> >> However, Stas says that mp2 won't work properly on the latest 5.8.1 >> without the fixups that having MP_NEED_HASH_SEED_FIXUP defined introduces. >> >> So: Is this a Perl or a mod_perl problem? >> >> Anything more I can do to help? I'm somewhat out of my depth here. > >I'm somewhat out of my depth here too
The maelstrom of waters surounding Win32's various mallocs when threaded are dangerous. The default perl malloc allocates of a thread-local heap, but you cannot call it until you are "far enough" into the initialization for the various indirections to be set up. Such memory is returned to the system on thread exit. (This is really part of the fork() faking, the pseudo-forked child gets its own heap so that its "polution" of the address space it shares with the parent can be quickly cleaned up without having hassle and time of free()ing every last thing.) If you call perl code from multiple threads it is vitally important to make sure you have told perl's C/C++ code which perl interpreter you are messing with. >... What I can add is >that, in the call to > ptr = (Malloc_t)PerlMem_malloc(size?size:1); >"size" has a value of 16, which is the correct value >corresponding to sizeof(apr_uuid_t) that >modperl_hash_seed_init() is calling it with. Also, although >this isn't the right thing, replacing the safemalloc() >call in modperl_hash_seed_init() with a malloc() call >allows the compilation to go through, but there's then >problems later on with the tests. Sounds like my nightmares with PerlIO in this space - you want a global memory allocator - there is one - but you have to keep things allocated by that away from normal perl objects which will attempt to realloc/free them to wrong pool. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
