Re: mingw check hung

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: mingw check hung
Дата
Msg-id 49807849.9070400@hagander.net
обсуждение исходный текст
Ответ на Re: mingw check hung  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: mingw check hung  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: mingw check hung  (Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk>)
Список pgsql-hackers
Andrew Dunstan wrote:
> 
> 
> Andrew Dunstan wrote:
>>
>>
>> Magnus Hagander wrote:
>>> Andrew Dunstan wrote:
>>>
>>>  
>>>> I've installed drmingw to handle exceptions instead, so we'll see if
>>>> that gives us useful info. If not, I'll see what I can do with gdb.
>>>>     
>>>
>>> Hadn't heard of drwmingw, I see how that can be useful :-)
>>>
>>>
>>>   
>>
>> report from DrMingw is below
>>
>>
> Further data point:
> 
> The suspect patch is quite definitely the source of the problem. I undid
> the configure changes and surrounded the additions to port/win32.h with
> #ifdef WIN32_ONLY_COMPILER ... #endif. Result: the problem disappeared,
> and "make check" completed perfectly.

Per discussion I looked at just reverting that part, but that won't
work. If we do that, the call to SetEnvironmentVariable() will not be
run, which certainly isn't right..

The problem has to be in win32env.c. I originally thought we
accidentally called the putenv function twice in this case, but that
code seems properly #ifdef:ed to MSVC.

I'm not sure I trust the crash point at all - is this compiled with
debug info enabled? It seems like a *very* strange line to crash on...

I can't spot the error right off :-( Can you try to see if it's the
putenv() or the unsetenv() that gets broken? (by making sure just one of
them get replaced)

//Magnus


В списке pgsql-hackers по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: Re: How to get SE-PostgreSQL acceptable
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Hot standby, recovery infra