[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Ipropd behavior when disk full?
I have a situation where ipropd has been growing to 1GB+ and crashing.
(Obviously the core files are a bit hard to deal with ;-)
It appears that the reason may be circular because the cause appears to
be the /var partition filling up. (which causes another core file that
a cron job tries/fails to copy to /var. . .)
Anyway, is it plausible that ipropd-slave (0.6.3) could have a problem
when it can't write to the DB which would make it leak memory or
otherwise grow explosively? The process size is stable (and only a few
MB) up until the last minute or so before it dies.
Is the following process trace consistent with that theory? (I would
have thought a disk write more likely than a strdup to be the the straw
that broke the program, but what do I know?)
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.4' in
core file header read successfully
program terminated by signal SEGV (no mapping at the fault address)
0xfef344e4: strlen+0x0080: ld [%o1], %o2
Current function is copy_general_string
dbx: warning: can't find file
dbx: warning: see `help finding-files'
(dbx) gdb on
 strlen(0x0, 0x12c, 0x21bb0, 0x7efefeff, 0x81010100, 0x16), at
 strdup(0x12c, 0x7531c, 0x4cc, 0xfefbc000, 0x0, 0x4cc), at
=> copy_general_string(from = 0x7a874, to = 0xffbff424), line 41 in
 copy_Realm(from = 0x7a874, to = 0xffbff424), line 67 in
 copy_Principal(from = 0xc, to = 0xffbff418), line 160 in
 hdb_principal2key(context = 0x7a868, p = 0x7a868, key =
0xffbff4a0), line 45 in "common.c"
 _hdb_remove(context = 0x7a868, db = 0x7b3c8, entry = 0xffbff518),
line 138 in "common.c"
 kadm5_log_replay_delete(context = 0x7b078, ver = 1U, len =
21195526U, sp = 0x581598), line 344 in "log.c"
 main(argc = 0, argv = 0x4cc), line 191 in "ipropd_slave.c"
This specific core file is 1.7 GB. I can provide more details as
relevant, but I don't think I can export the whole file.
TIA for any comments.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or email@example.com