William A. Rowe Jr. wrote on 2011-02-04: > On 2/4/2011 4:51 AM, Steve Hay wrote: >> The crash comes here (which is exactly where the Apache/mod_perl setup >> was crashing): >> >> msvcr100.dll!free(void * pBlock) Line 51 C >> msvcr100.dll!__crtsetenv(char * * poption, const int primary) Line >> 211 + 0xa bytes C msvcr100.dll!_putenv_helper(const char * name, >> const char * value) Line 265 + 0xb bytes C >> msvcr100.dll!_putenv(const char * option) Line 77 + 0xa bytes C >> test.exe!main(int argc, char * * argv, char * * env) Line 97 + 0xb >> bytes C++ test.exe!__tmainCRTStartup() Line 555 + 0x17 bytes >> C >> Can anyone shed any light on what the problem is? In particular, can >> it be fixed (or at least worked around) in the Apache code, or is this >> a problem with msvcr100.dll? > > Possibly foolish question, but are all of the components built on the > same MSVCRxxx compiler? This is pretty typical of mismatch behavior, > where for example apr and msvcr90 set up the envvars and msvcr100 then > tries to free those allocations.
Yes, Apache, Perl and mod_perl were all brand-new builds done one immediately after another on the same machine, using the same VS2010 installation for them all. Also, note that the test.cpp program that I attached in my original post (which you've quoted the stack trace from above) is a self-contained standalone program, not linked to anything other than standard MS libraries. The functions in it are copied directly from the APR code with just minor renaming, macro expansion and comment removal. Actually, there is one comment in httpd-2.2.17\srclib\apr\misc\win32\apr_app.c that sounds very pertinent: * _dbg_malloc/realloc is used in place of the usual API, in order * to convince the MSVCRT that it created these entities. If we * do not create them as _CRT_BLOCK entities, the crt will fault * on an assert. We are not worrying about the crt's locks here, * since we are single threaded [so far]. 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?
