Thread: pg_restore crashes passing NULL to strcmp (9.4 rc1)
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;
(gdb) p ReadStr(AH)
$1 = 0x0
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
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