Skip site navigation (1) Skip section navigation (2)

Re: mingw check hung

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mingw check hung
Date: 2009-01-30 08:03:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan wrote:
> Magnus Hagander wrote:
>> Andrew Dunstan wrote:
>>> Magnus Hagander wrote:
>>>>> Specifically, it's the SetEnvironmentVariable() call from
>>>>> pgwin32_putenv() called from pgwin32_unsetenv(). When this is disabled
>>>>> things work just fine.
>>>> That's strange :( What arguments are it sent to the function? Since
>>>> this
>>>> is an API function, it really shouldn't behave differently between
>>>> mingw
>>>> and msvc, so it must be something that goes wrong with the arguments.
>>>> Also, Tom mentioned earlier that we may be including *two* replacements
>>>> for unsetenv(), which could be what's causing the problem. Can you
>>>> check
>>>> if that is happening and try to disable the one in port/unsetenv.c and
>>>> see if that changes things?
>>> I've already ruled out that hypothesis by forcing the call direct to
>>> pgwin32_unsetenv() instead of relying on the macro, in initdb.c.
>>> There are only two such calls in initdb.c: the arguments are "LC_ALL"
>>> I wonder if this version of SetEnvironmentVariable is sufficiently dumb
>>> that it fails badly if given a NULL second argument for a value that is
>>> not in fact in the environment (as I would normally expect of these on
>>> Windows)?
>> But that should be a win32 API call. It's not a runtime call. So it
>> should be identical between mingw and msvc!
>> Try removing the code that sets it to NULL if it's empty string. Having
>> it as empty string made it fail on MSVC, and the API documentation says
>> it should be NULL, but maybe mingw is somehow intercepting the call and
>> breaking it...
> Mingw is just passing the call on.
> You're right. When I comment out the NULL assignment, it all works.
> MSDN says this (<>):
>    If the value parameter is not empty and the environment variable
>    named by the variable parameter does not exist, the environment
>    variable is created and assigned the contents of value. Solely for
>    purposes of this operation, value is considered empty if it is a
>    null reference (Nothing in Visual Basic), contains a zero-length
>    string, or contains an initial hexadecimal zero character (0x00).
>    If variable contains a non-initial hexadecimal zero character, the
>    characters before the zero character are considered the environment
>    variable name and all subsequent characters are ignored.
>    If value contains a non-initial hexadecimal zero character, the
>    characters before the zero character are assigned to the environment
>    variable and all subsequent characters are ignored.
>    If value is empty and the environment variable named by variable
>    exists, the environment variable is deleted. If variable does not
>    exist, no error occurs even though the operation cannot be performed.
> So it looks like we could remove that NULL assignment happily and expect
> the right thing to be done.

I'm doing training all day today, but I can hopefully look at it this
weekend if you haven't already. However, I do recall *adding* that part
specifically for MSVC compatibility - I got a crash without it. Perhaps
we need to #ifdef it on mingw, but I'd like to understand *why*, since
it's just an API call...

Are we *sure*, btw, that this is actually a mingw issue, and not
something else in the environment? Could you try a MSVC compiled binary
on the same machine?


In response to


pgsql-hackers by date

Next:From: ITAGAKI TakahiroDate: 2009-01-30 08:13:25
Subject: Re: using composite types in insert/update
Previous:From: Heikki LinnakangasDate: 2009-01-30 06:16:07
Subject: Re: [PATCH] Space reservation v02

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group