Steve Peters via RT wrote:

>>[aa29 - Thu Apr 08 01:12:56 2004]:
>>
>>To: [EMAIL PROTECTED]
>>Subject: Perl segfaults if XS changes system environment
>>Reply-To: [EMAIL PROTECTED]
>>Message-Id: <[EMAIL PROTECTED]>
>>
>>This is a bug report for perl from [EMAIL PROTECTED],
>>generated with the help of perlbug 1.35 running under perl v5.8.4.
>>
>>Perl (Win32) segfaults with "free to wrong pool..." message during
>>interpreter
>>destruction phase IF:
>>
>> 1. destruct_level > 0
>> 2. XS changes system environment
>>
>>I hit this problem while installing Apache::DBI, which is using DBD::mysql
>>in the test suite.
>>
>>Short example is:
>>
>>use DBI;
>>use threads; # to set destruct_level
>>my $dbh = DBI->connect('dbi:mysql:test');
>>
>>Code digging shows that Win32 port gets environ from stdlib. In
>>construction phase PL_origenviron is set to environ. If
>>    
>>
>destruct_level's not
>  
>
>>0 in destruction phase PL_origenviron is compared with environ and if it's
>>not the same there's an attempt to safesysfree(environ) wich segfaults.
>>
>>PL_origenviron and environ became different after putenv call in XS or
>>underlying library (as mysqllib).
>>
>>Possible patch is:
>>
>>--- perl.c.orig 2004-04-07 20:01:43.171875000 +0400
>>+++ perl.c 2004-04-07 20:01:01.234375000 +0400
>>@@ -589,7 +589,7 @@
>>      * so we certainly shouldn't free it here
>>      */
>> #ifndef PERL_MICRO
>>-#if defined(USE_ENVIRON_ARRAY) && !defined(PERL_USE_SAFE_PUTENV)
>>+#if defined(USE_ENVIRON_ARRAY) && !defined(PERL_USE_SAFE_PUTENV) &&
>>!defined(WIN32)
>>     if (environ != PL_origenviron
>> #ifdef USE_ITHREADS
>>  /* only main thread can free environ[0] contents */
>>    
>>
>
>I updated the title on this ticket so that it will be noticed by people
>more clueful on Win32 than I.
>
>Does everything above make sense?  Will the patch prevent the faults on
>Win32?
>
I've long had "Free to wrong pool" errors with much the same simple 
program.  I once asked about it on dbi-users:

http://www.mail-archive.com/dbi-users@perl.org/msg22595.html

If you follow the thread to the next message you'll see that Tim Bunce's 
solution was simply not to use threads.  In his own words threads is a 
whole new (big) can of worms, so it sounds to me like even if the above 
does fix the particular problem in that simple program then you'll still 
get plenty of other similar problems elsewhere.

According to its own manpage 
(http://search.cpan.org/~timb/DBI-1.48/DBI.pm#Threads_and_Thread_Safety) 
DBI is not yet ready for perl threads.  There are sure to be more 
problems than just the above.



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

Reply via email to