On Mon, Feb 02, 2009 at 07:37:46AM -0500, Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> >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, b
Magnus Hagander wrote:
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
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.
>>>
Andrew Dunstan wrote:
Even weirder. It has now started working. For no apparent reason. I am
seriously confused.
I spoke too soon :-(
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dawn_bat&dt=2009-01-31%2016:28:16
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hacker
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
Hi.
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?
Both they look at a problem.
http://winpg.jp/~saito/pg_bug/20090124/
Then, If SetEnvironmentVariable of Andrew-san point is removed,
a problem will clearvery
Hiroshi Inoue wrote:
> Andrew Dunstan wrote:
>>
>>
>> Andrew Dunstan wrote:
>>>
>>>
>>> Magnus Hagander wrote:
Andrew Dunstan wrote:
> Magnus Hagander wrote:
>
>> Are we *sure*, btw, that this is actually a mingw issue, and not
>> something else in the environment? Cou
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 i
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 t
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
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?
My
Andrew Dunstan wrote:
> > Anyway, yes, I think that would be OK. How do we then test to see if
> > the original problem is still fixed?
> >
> >
>
> Further proof that this is a Windows version issue: I took the problem
> build from my XP and put it on my Vista box: the same build that causes
>
Andrew Dunstan wrote:
Magnus Hagander wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
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?
My MSVC buildfarm animal
Magnus Hagander wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
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?
My MSVC buildfarm animal runs on the same machin
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>> 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?
>>
>
> My MSVC buildfarm animal runs on the same machine, and does not s
Magnus Hagander wrote:
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?
My MSVC buildfarm animal runs on the same machine, and does not suffer
the same problem.
cheers
andrew
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.
>
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 th
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
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
Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
>>
>>
>> Tom Lane wrote:
>>> Magnus Hagander writes:
>>>
Andrew Dunstan wrote:
> The suspect patch is quite definitely the source of the problem.
>
>>>
>>>
I can't spot the error right off :-( Can you try to s
Andrew Dunstan wrote:
Tom Lane wrote:
Magnus Hagander writes:
Andrew Dunstan wrote:
The suspect patch is quite definitely the source of the problem.
I can't spot the error right off :-( Can you try to see if it's the
putenv() or the unsetenv() that gets broken?
Ar
Tom Lane wrote:
Magnus Hagander writes:
Andrew Dunstan wrote:
The suspect patch is quite definitely the source of the problem.
I can't spot the error right off :-( Can you try to see if it's the
putenv() or the unsetenv() that gets broken?
Are we sure pgwin32_unse
Mark Cave-Ayland wrote:
> Magnus Hagander wrote:
>
>> 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 w
Magnus Hagander wrote:
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 functio
Magnus Hagander writes:
> Andrew Dunstan wrote:
>> The suspect patch is quite definitely the source of the problem.
> I can't spot the error right off :-( Can you try to see if it's the
> putenv() or the unsetenv() that gets broken?
Are we sure pgwin32_unsetenv works in this environment? (Or wo
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 o
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
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
cheer
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>>
>>
>> Have you managed to get gdb running on that box, and if so, can you try
>> to grab a stacktrace? If not, try a stacktrace from process explorer. It
>> doesn't actually work with mingw, but it gives you a hint based on DLL
>> exports...
>
Magnus Hagander wrote:
Have you managed to get gdb running on that box, and if so, can you try
to grab a stacktrace? If not, try a stacktrace from process explorer. It
doesn't actually work with mingw, but it gives you a hint based on DLL
exports...
I'll see what I can do. By the time
Andrew Dunstan wrote:
>
>
> Andrew Dunstan wrote:
>>
>> Something happened about 80 hours ago that caused my mingw buildfarm
>> member (gcc 3.4.2 on Win XP Pro SP2) to hang at the check stage. It
>> looks like it's hung in initdb.
>>
>> I wonder if it could be this commit:
>>
>> Log Message:
>> -
Andrew Dunstan wrote:
Something happened about 80 hours ago that caused my mingw buildfarm
member (gcc 3.4.2 on Win XP Pro SP2) to hang at the check stage. It
looks like it's hung in initdb.
I wonder if it could be this commit:
Log Message:
---
Make win32 builds always do SetEnvir
Something happened about 80 hours ago that caused my mingw buildfarm
member (gcc 3.4.2 on Win XP Pro SP2) to hang at the check stage. It
looks like it's hung in initdb.
I wonder if it could be this commit:
Log Message:
---
Make win32 builds always do SetEnvironmentVariable() when doi
33 matches
Mail list logo
