pg_restore crashes passing NULL to strcmp (9.4 rc1)

On 12/06/2014 08:11 AM, Justin Pryzby wrote:

I'm not sure what's wrong with this dump file; I remember copying it with rsync
some months ago, experiencing the crash, and recopying it, not able to break
off and go into debugging postgres at that point.

$ dpkg-query -W postgresql-client-9.4
postgresql-client-9.4 9.4~rc1-1

(gdb) r
Starting program: /usr/lib/postgresql/9.4/bin/pg_restore /home/pryzbyj/clientdb/ptci.d/ptci.segv
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
ReadToc (AH=AH@entry=0x55555577b3b0)
at /build/buildd/postgresql-9.4-9.4~rc1/build/../src/bin/pg_dump/pg_backup_archiver.c:2426
2426 /build/buildd/postgresql-9.4-9.4~rc1/build/../src/bin/pg_dump/pg_backup_archiver.c: No such file or directory.

2422 te->owner = ReadStr(AH);
2423 if (AH->version >= K_VERS_1_9)
2424 {
2425 if (strcmp(ReadStr(AH), "true") == 0)
2426 te->withOids = true;
2427 else
2428 te->withOids = false;
2429 }
2430 else
2431 te->withOids = true;

Hmm. It's a bit hard to believe that the "te->withOids = true"
assignment could've segfaulted. So the line number probably isn't 100%
accurate.

A corrupted dump file can certainly cause a segfault in pg_restore, so
the dump file was probably somehow damaged while copying it with rsync.
Can't say more than that, I'm afraid, without the dump file itself.

(gdb) p ReadStr(AH)
$1 = 0x0

That tries reads the *next* string from the dump file, so it's not very
surprising that that fails. The previous ReadStr() call probably failed
already, and it would be more interesting to to see what went wrong there.

- Heikki

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Heikki Linnakangas <hlinnakangas@vmware.com> writes:

On 12/06/2014 08:11 AM, Justin Pryzby wrote:

I'm not sure what's wrong with this dump file; I remember copying it with rsync
some months ago, experiencing the crash, and recopying it, not able to break
off and go into debugging postgres at that point.

A corrupted dump file can certainly cause a segfault in pg_restore, so
the dump file was probably somehow damaged while copying it with rsync.
Can't say more than that, I'm afraid, without the dump file itself.

Yeah, I think this sounds like "rsync screwed up".

That tries reads the *next* string from the dump file, so it's not very
surprising that that fails. The previous ReadStr() call probably failed
already, and it would be more interesting to to see what went wrong there.

AFAICS, the only thing that would cause ReadStr to return NULL (rather
than failing internally) would be having read a negative length word
from the file. So it's hard to come to any conclusion other than that
the file is corrupt. There are various subcases of that but it all
comes out to the same place in the end --- especially if recopying
the original file produced a valid readable file.

Possibly this bug report should be interpreted as "we should strive
to make pg_restore yield an appropriate error message rather than ever
dumping core, no matter what's wrong with the input file". It would not
be too hard to fix this specific case, but trying to ensure that we've
gotten rid of every other case would probably be a huge amount of work
for not much reward :-(

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs