Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> Andrew Dunstan wrote:
>>
>>> Hiroshi Inoue wrote:
>>>
>>>> Eventually does the crash come from the call SetEnvironemntVariable
>>>> (.., NULL) on mingw-XP(or older?)?
>>>> I'm also interested in this issue and want to know the cause.
>>>>
>>>>
>>>>
>>> The debugger shows that we actually fail on a popen() call in intdb.
>>> However, if we replace the calls to SetEnvironmentVariable("foo",NULL)
>>> with calls to SetEnvironmentVariable("foo","") then there is no failure.
>>> My theory is that on XP somehow the former is corrupting the environment
>>> such that when popen() tries to copy the environment for the new child
>>> process, it barfs.
>>>
>>
>> Well, XP only does it when it's built with mingw!
>>
>> Or is this actually dependent on if the binary is run under msys or cmd?
>>
>>
>>
>
> Even weirder. It has now started working. For no apparent reason. I am
> seriously confused.
This is just strange :S
We could #ifdef out that thing on mingw, but I'm still worried that it
will not work in all cases. I'd like to think there's a reason that
thing was in there in the first place.
Hmm. Actually, if I look at how things were before, I think we only
called SetEnvironmentVariable() in case we set a variable, and never if
we removed one. I'm not sure that's correct behavior, but it's
apparently non-crashing behavior. Perhaps we need to restore that one?
I'd be in favor of restoring it for both mingw and msvc in that case -
that way we keep the platforms as close to each other as possible.
Comments?
//Magnus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
