Thread: BUG #2769: "invalid memory alloc request size " on startup
The following bug has been logged online: Bug reference: 2769 Logged by: Chris Jones Email address: chris@cjones.org PostgreSQL version: 8.0.9 Operating system: NetBSD 2.0.2 Description: "invalid memory alloc request size <n>" on startup Details: After several uncontrolled reboots of the server, one of my hosted sites' databases is giving an error on any attempt to connect to the DB. Trying to distill this down to the simplest case possible, I stopped the postmaster and ran postgres in standalone mode, with just that database. Setting the debug level didn't seem to accomplish anything: pgsql@maxine$ postgres -D data -d 5 drupal_dearslut FATAL: invalid memory alloc request size 1095237632 The logs have only that 1 line in them, as well. PostgreSQL 8.0.9 on i386--netbsdelf, compiled by GCC gcc (GCC) 3.3.3 (NetBSD nb3 20040520) maxine$ uname -a NetBSD maxine.cjones.org 2.0.2 NetBSD 2.0.2 (GENERIC) #0: Wed Mar 23 08:53:42 UTC 2005 jmc@faith.netbsd.org:/home/builds/ab/netbsd-2-0-2-RELEASE/i386/200503220140Z -obj/home/builds/ab/netbsd-2-0-2-RELEASE/src/sys/arch/i386/compile/GENERIC i386 I used to be decent with gdb, so let me know if there's anything I can do as far as backtraces, etc. Alternatively, if it's possible to get a consistent dump of this DB, I could just upgrade to 8.1. Chris
"Chris Jones" <chris@cjones.org> writes:
> After several uncontrolled reboots of the server, one of my hosted sites'
> databases is giving an error on any attempt to connect to the DB. Trying to
> distill this down to the simplest case possible, I stopped the postmaster
> and ran postgres in standalone mode, with just that database. Setting the
> debug level didn't seem to accomplish anything:
> pgsql@maxine$ postgres -D data -d 5 drupal_dearslut
> FATAL: invalid memory alloc request size 1095237632
This looks like a problem of corrupt data in one of the system catalogs
or its indexes, but there's not enough info here to guess where.
> I used to be decent with gdb, so let me know if there's anything I can do as
> far as backtraces, etc.
Try setting a breakpoint at errfinish() and backtracing from there.
regards, tom lane
Chris Jones <chris@cjones.org> writes:
> #0 0x081cd8ba in errfinish ()
> #1 0x081ce756 in elog_finish ()
> #2 0x081dd6e5 in MemoryContextAlloc ()
> #3 0x081ca14c in load_relcache_init_file ()
> #4 0x081c9164 in RelationCacheInitialize ()
Hmph. Apparently there is something wrong with the pg_internal.init
file in this database.
> I've dropped this database and restored it from backups to get it
> running again.
That was premature --- you could have just removed the broken init file
(which is merely a cache). I'm not sure how easy it'll be to identify
the problem with the cache file without an easy way to compare to valid
data, but if you want to send me the saved-off init file I'll take a
look. Which PG version is this again?
regards, tom lane
Tom Lane wrote: > "Chris Jones" <chris@cjones.org> writes: >> I used to be decent with gdb, so let me know if there's anything I can do as >> far as backtraces, etc. > > Try setting a breakpoint at errfinish() and backtracing from there. Breakpoint 1, 0x081cd8ba in errfinish () (gdb) bt #0 0x081cd8ba in errfinish () #1 0x081ce756 in elog_finish () #2 0x081dd6e5 in MemoryContextAlloc () #3 0x081ca14c in load_relcache_init_file () #4 0x081c9164 in RelationCacheInitialize () #5 0x081d4dfe in InitPostgres () #6 0x0816facb in PostgresMain () #7 0x0811e04d in main () #8 0x08072e22 in ___start () Because it was built without debugging symbols, I think this is all I can get for you. I've dropped this database and restored it from backups to get it running again. But I've also kept a copy of the erroneous data for bug-hunting purposes. If you'd like to track this down and/or find a way to automatically clean up data corrupted in this fashion, I'll be happy to work with you. If you have no interest, please let me know so I can delete the files. Chris