Re: mingw check hung
От | Magnus Hagander |
---|---|
Тема | Re: mingw check hung |
Дата | |
Msg-id | 4986E414.4040106@hagander.net обсуждение исходный текст |
Ответ на | Re: mingw check hung (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: mingw check hung
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: