Steve Hay wrote on 2011-02-04:
> William A. Rowe Jr. wrote on 2011-02-04:
>> On 2/4/2011 3:49 PM, Steve Hay wrote:
>>> It looks like the original environ[] was allocated by msvcr100.dll
>> using something other than a function matching the HeapFree() function
>> where the crash finally happens. The CRT code is trying to free the
>> existing PATH in its environment before setting the new value coming
>> from _putenv(), and it is that free that crashes, presumably because
>> the APR re-processing of the environ entities didn't fool MSVCRT well
>> enough?
>> 
>> That makes sense, and it should be easy to make that conditional on the
>> vc version. Now the question is where were these allocated from in
>> MSVCR100? Only a trip through the crt sources will help out, there.
> 
> Indeed, but looking through the VS2010 CRT source code the environment
> seems to be initialized in stdenvp.c using _calloc_crt, which should
> match the _free_crt call in setenv.c line 211 where it all goes wrong,
> so I'm confused why it's crashing. The VS2008 CRT source code looks the
> same in this area too.

The attached modified version of my original test program no longer crashes, 
but I'm not sure whether the environment re-processing still achieves what it 
is meant to.

The only change is that it now does the UTF-8 conversion into env and then 
copies that to _environ, rather than converting into _environ and then copying 
that to env.

I don't understand why that makes the crash go away, but if it really does (I 
have yet to rebuild Apache/APR/mod_perl to exercise it more fully) and if it 
still achieves what it is meant to do then would a similar change be accepted 
into the APR source (unless somebody comes up with a better solution)?

Should I move this thread to the apr-dev list now?

Attachment: test.cpp
Description: test.cpp

Reply via email to