Re: mingw check hung - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: mingw check hung
Date
Msg-id 49807849.9070400@hagander.net
Whole thread Raw
In response to Re: mingw check hung  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: mingw check hung  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: mingw check hung  (Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk>)
List 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 by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: How to get SE-PostgreSQL acceptable
Next
From: Simon Riggs
Date:
Subject: Re: Hot standby, recovery infra