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

Re: BUG #6208: crash when c: occupied by removable drive

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: "Bayer G(dot) Richard" <bayer(at)nws(dot)cz>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #6208: crash when c: occupied by removable drive
Date: 2011-09-18 10:40:08
Message-ID: 4E75CA88.3080506@ringerc.id.au (view raw or flat)
Thread:
Lists: pgsql-bugs
Please reply all or reply to the pgsql-bugs list, not direct to me.

My response follows inline.

On 18/09/2011 2:03 PM, Bayer G. Richard wrote:
>
> The suspicious library is the libpq.dll that the application uses to 
> connect to a database.
>
> On the machine the problem is there are no developer tools. With the 
> vendor of the software
> we pinpointed the problem with a primitive approach using MsgBoxes, so 
> we found that
> it is the call to the library function that crashes the app.
>
OK, that's the immediate cause, but not necessarily the root cause 
("bug"). You can crash in a library by passing a null `char*' where it 
expects a valid pointer, by passing a wrong length parameter or a 
too-short struct, by having a corrupt heap you haven't detected yet, or 
all sorts of other ways.

That doesn't mean there isn't a bug in libpq, just that it's not 
necessarily as simple as "it crashed in libpq so the bug is in libpq".

> I even can not specify the term “call to library function” better
>
Ah, so you're not the author of the program having problems?

Can you get the author/vendor to get in touch, or to submit a test-case?

 > I wrote the rest in the description.
 >
 > In short: no C: at all worked, but having a drive with removable 
media mapped to C: with
 > no media in it caused trouble.

Yeah, but that's not all that much information.  It'd be really good to 
know which _exact_ function call failed? With which arguments? Does it 
still fail when run in a cut-down test program that only does the 
minimum work required to make that function call?

I'm not enthusiastic about setting up a weirdly configured Windows VM to 
play with this. I suffer Windows development in my free time too much 
already :S

> All I know is that it is the call
> where the IP of the server is first used (some kind of connect() maybe)
>

OK, that's something. It's probably PQconnectdbParams(...), 
PQconnectdb(...), PQsetdbLogin(...) or PQsetdb(...), assuming you're 
actually using libpq directly. You might be using libpq via PgODBC 
though. Again, a test case or backtrace (from the vendor perhaps?) would 
really help; as you can see even if it is libpq there are still a lot of 
unknown variables with the amount of information you've provided.

I realise you don't want to spend more time on this, so it's up to you 
whether you follow up with the vendor of your software and get a decent 
test case or a backtrace or something. Even if you could test with 
PgAgent III and verify that *it* crashes when you connect to the 
database, that'd help.

If you don't want to do more, it's possible that one of the more 
Windows-focused PostgreSQL outfits like EnterpriseDB might pick this up 
and look into it, but given the weird nature of the problem config it's 
just as likely they won't be able to justify the time/cost. Unless you 
can at least show that it crashes psql or PgAgent III there isn't even 
any convincing evidence it's not just a bug in the vendor's app that's 
being tripped over inside a call to libpq.

--
Craig Ringer

In response to

pgsql-bugs by date

Next:From: Robert HaasDate: 2011-09-18 21:10:05
Subject: Re: BUG #6205: ERROR: temporary tables cannot specify a schema name
Previous:From: Craig RingerDate: 2011-09-17 22:59:57
Subject: Re: BUG #6208: crash when c: occupied by removable drive

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