perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject Re: [PATCH] Re: What Perl configuration is required for mp2 on Win32?
Date Wed, 02 Feb 2005 08:44:50 GMT
Steve Hay wrote:

>Philippe M. Chiasson wrote:
>
>  
>
>>Steve Hay 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.
>>>>>>>           
>>>>>>>
>>>>>>>              
>>>>>>>
>>>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?
>>>   
>>>
>>>      
>>>
>>PERL_SYS_(TERM|INIT) needs to be called only once in the parent process.
>>Can you give this patch a spin ?
>> 
>>
>>    
>>
>Didn't work, I'm afraid :(
>  
>
No replies to this one, then :(

Are people still pondering it, or does nobody know how to resolve this?

It seems to me that mp2 really should be calling PERL_SYS_INIT3() and 
PERL_SYS_TERM().  All the examples in perlembed.pod show these macros 
being used, and I have a trivial C program (posted previously) that 
breaks without them.  Their omission is very likely at least part of the 
cause for mp2 not working in my setup, and I'd really like to get it 
sorted out somehow.

- 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message