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

Re: pg_dump fails to dump database

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: M(dot)Hankus(at)ce3(dot)pl, pgsql-bugs(at)postgresql(dot)org, Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Subject: Re: pg_dump fails to dump database
Date: 2000-12-17 17:36:23
Message-ID: 20957.977074583@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
pgsql-bugs(at)postgresql(dot)org writes:
> pg_dump in postgreSQL 7.0.3 fails to dump database. Problem is
> becomeUser procedure in which lastusername stores pointer to name of
> username which is currently connected. becomeUser is called for the
> first time in dumpSchema, which allocated memory, calls becomeUser and
> then frees memory. Then becomeUser is called again during dumping of
> table data, but lastusername points to deallocated memory, so it
> receives SIGSEGV (in strcmp).

Hm.  This is clearly erroneous code, but the odds of a coredump seem
*extremely* remote --- as borne out by the fact that this bug has been
in there for a good long while, and hasn't been noticed before.
strcmp as such isn't going to care whether the string it's pointed
at has been freed and/or overwritten.  It could only coredump if it
scanned past the end of physically allocated memory before hitting a
null, and that seems pretty unlikely, especially given that the other
input string is likely to be short.  What sort of platform are you
running on?

Philip, I see that becomeUser is toast in current sources, but it
seems like _reconnectAsUser might still have the same logic flaw;
wouldn't it be a good idea to make it strdup the value it saves in
currUser?

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2000-12-17 18:05:48
Subject: Re: Table name scope (was Re: Outer joins aren't working with views)
Previous:From: pgsql-bugsDate: 2000-12-17 11:09:48
Subject: pg_dump fails to dump database

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