Dave Mitchell wrote: >On Thu, Jul 07, 2005 at 01:56:39PM +0100, Steve Hay wrote: > > >>Hmm. I just retried this with current blead and I find that it >>(apparently) works OK with a debug build, but crashes with a release build. >> >> > >I can't get it to crash on either type of build (Linux). > > :-(
>>Fortunately, release builds on Win32 have debugging symbols anyway >>(since they are stored in separate files), so I am able to get a stack >>trace: >> >>win32_checkTLS(interpreter * 0x73204441) line 57 >>PerlEnvGetenv(IPerlEnv * 0x01857670, const char * 0x280b79b8 `string') >>line 454 + 19 bytes >>PerlIO_debug(const char * 0x280b79e0 `string') line 461 + 14 bytes >>PerlIO_clone(interpreter * 0x018b2ad4, interpreter * 0x00234494, >>clone_params * 0x0140fc80) line 643 >>perl_clone_using(interpreter * 0x00234494, unsigned long 6, IPerlMem * >>0x0185761c, IPerlMem * 0x01857638, IPerlMem * 0x01857654, IPerlEnv * >>0x01857670, IPerlStdIO * 0x018576a8, IPerlLIO * 0x01857744, IPerlDir * >>0x018577ac, IPerlSock * 0x018577d8, IPerlProc * 0x01857888) line 11383 >>perl_clone_host(interpreter * 0x00234494, unsigned long 6) line 315 + 67 >>bytes >>perl_clone(interpreter * 0x00234494, unsigned long 6) line 11183 + 11 bytes >>Perl_ithread_create(interpreter * 0x00000000, sv * 0x00000000, char * >>0x018325e4, sv * 0x002354cc, sv * 0x01828c64) line 424 + 8 bytes >>XS_threads_new(interpreter * 0x00000002, cv * 0x018a83f4) line 687 + 32 >>bytes >>Perl_pp_entersub(interpreter * 0x01234494) line 2789 >>Perl_runops_standard(interpreter * 0x00234494) line 38 + 45 bytes >>S_run_body(interpreter * 0x00234494, long 1) line 2231 + 10 bytes >>perl_run(interpreter * 0x00234494) line 2160 + 10 bytes >>RunPerl(int 3, char * * 0x00232440, char * * 0x00232d08) line 217 + 6 bytes >>PERL! mainCRTStartup + 227 bytes >>KERNEL32! 77e8141a() >> >> > >threads->new() tries to clone an intepreter; this calls PerlIO_clone(), >which calls PerlIO_debug(), which tries to get the value (if any) of >the env var PERLIO_DEBUG. At this point it jumps into windows-specific >code, where it then crashes. > >Does it still fail after change 25094? I'm pretty much clutching at straws >here, but that does hapen to fix an unrelated bug associated with doing >'local $0' > No, it still crashes with much the same stack trace. The crash is deliberately forced by win32_checkTLS(), but I don't understand for what reason. PerlEnvGetenv() takes an IPerlEnv* and uses the IPERL2HOST() macro (which is set to IPerlEnv2Host()) to locate the CPerlHost* which that IPerlEnv* is a member of. It then calls win32_checkTLS() to check that the host_perl in the CPerlHost* that has been found is my_perl. Evidently, in this case host_perl != my_perl, so it bombs out. Does anyone know what this my_perl is? What is the purpose of the host_perl != my_perl check, and why might it be failing? ------------------------------------------------ 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.
