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
