Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>
>>>Steve Hay wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Therefore, I want to configure my Perl with MULTIPLICITY and
>>>>USE_ITHREADS, but not PERL_IMPLICIT_SYS. That way, I can enable
>>>>PERL_MALLOC.
>>>>
>>>>I've tried doing exactly this, but it doesn't seem to work. Perl
>>>>(5.8.6) itself built and tested without error, and mp2 (RC4) also built
>>>>without error. However, the mp2 test suite won't even get off the ground.
>>>>
>>>>
>>>>
>>>>
>>>I'd ask Jan or some other ActiveState folks directly or via p5p (not sure
>>>if there is a special activestate perl list).
>>>
>>>
>>>
>>I believe Jan (and others at ActiveState?) read this list anyway, but
>>why would they know what is required for mp2?
>>
>>
>
>I was talking about the segfaults that you were getting. Those have
>nothing to do with mp2, I believe. Other than being a trigger.
>
Thanks for kicking my butt on this.
Your comment made me start looking at how to reproduce the segfault
without mp2 being involved (otherwise it'd be hard to get p5p
interested), which turned out to be very simple: The following tiny
program, taken from an example in the perlembed manpage is all that it took:
#include "EXTERN.h"
#include "perl.h"
static PerlInterpreter *my_perl;
int main(int argc, char **argv, char **env) {
PERL_SYS_INIT3(&argc, &argv, &env);
my_perl = perl_alloc();
perl_construct(my_perl);
perl_destruct(my_perl);
perl_free(my_perl);
PERL_SYS_TERM();
}
The above program works fine (using my ithreads-but-no-impsys perl), but
segfaults in the same way as apache/mp2 if I omit the PERL_SYS_INIT3()
(and PERL_SYS_TERM) call(s):
Perl_malloc(unsigned int 1020) line 1458
S_more_sv(interpreter * 0x00853fe0) line 315 + 10 bytes
Perl_newSV(interpreter * 0x00853fe0, unsigned int 79) line 4561 + 76 bytes
perl_construct(interpreter * 0x00853fe0) line 267 + 11 bytes
main(int 1, char * * 0x00852bf0, char * * 0x00852fd0) line 7 + 11 bytes
EMBED! mainCRTStartup + 227 bytes
KERNEL32! 77e8141a()
Now, looking at the mp2 source, I see that modperl_startup() (the
function which calls perl_construct()) does not have a PERL_SYS_INIT3()
call in it. Adding one as per the attached patch (against svn rev
149266) fixes my problem. The entire test suite now passes all tests OK
in this configuration. (I had to SKIP t/perl/ithreads*.t again, though
-- it crashed the server again the first time I tried with them still in
place :-s Not sure if this patch re-introduces that failure, or if it
never really went away. Maybe I've just been lucky with it working
recently?)
However, we presumably now need to add a corresponding PERL_SYS_TERM()
somewhere? I tried slipping one into modperl_perl_destruct() like this:
Index: src/modules/perl/modperl_perl.c
===================================================================
--- src/modules/perl/modperl_perl.c (revision 149266)
+++ src/modules/perl/modperl_perl.c (working copy)
@@ -184,6 +184,8 @@
perl_free(perl);
#endif
+ PERL_SYS_TERM();
+
#ifdef USE_ENVIRON_ARRAY
if (orig_environ) {
environ = orig_environ;
but that didn't work: it makes the server crash on startup again.
Again, it crashes on a MALLOC_LOCK line, but now during some
destroy/cleanup code:
Perl_mfree(void * 0x01f7f568) line 2092
Perl_sv_clear(interpreter * 0x04deb730, sv * 0x01ec0e90) line 5231 + 13
bytes
Perl_sv_free(interpreter * 0x04deb730, sv * 0x01ec0e90) line 5376 + 13 bytes
Perl_av_clear(interpreter * 0x04deb730, av * 0x01f26d7c) line 470 + 13 bytes
modperl_xs_dl_handles_get(interpreter * 0x04deb730) line 300 + 13 bytes
modperl_interp_destroy(modperl_interp_t * 0x04dec9a8) line 143 + 9 bytes
modperl_interp_pool_destroy(void * 0x0098c238) line 201 + 12 bytes
run_cleanups(cleanup_t * * 0x00984b80) line 1951 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x00984b70) line 730 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0029afc8) line 690 + 12 bytes
main(int 11, const char * const * 0x00298508) line 576
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e8141a()
Any ideas how to sort that out?
Incidentally, the example program above runs fine with ActivePerl Build
811 (ithreads and impsys) even with the PERL_SYS_INIT3()/PERL_SYS_TERM()
calls removed, which could explain why this problem has gone undetected
for so long?
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Index: src/modules/perl/mod_perl.c
===================================================================
--- src/modules/perl/mod_perl.c (revision 149266)
+++ src/modules/perl/mod_perl.c (working copy)
@@ -191,6 +191,7 @@
PerlInterpreter *perl;
int status;
char **argv;
+ char **env;
int argc;
#ifndef USE_ITHREADS
modperl_cleanup_data_t *cdata;
@@ -234,6 +235,8 @@
argv = modperl_config_srv_argv_init(scfg, &argc);
+ PERL_SYS_INIT3(&argc, &argv, &env);
+
if (!(perl = perl_alloc())) {
perror("perl_alloc");
exit(1);
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
