According to Sean Downey: > I ran > "gdb /path/to/htmerge /path/to/core" then "bt", > > as suggested in > http://www.geocrawler.com/mail/msg.php3?msg_id=8091212&list=8822 > (sorry I didn't notice those posts earlier)
That's OK. The Geocrawler archives aren't exactly easy to search. That tip is mentioned in the FAQ as well, though. I should have thought to recommend it. > this is the output I got - I hope it's of some help Yes, that really does seem to pinpoint things... > (gdb) bt > #0 0x282453bc in kill () from /usr/lib/libc.so.4 > #1 0x28281026 in abort () from /usr/lib/libc.so.4 > #2 0x28077e30 in __terminate () at HtHTTPBasic.cc:33 > #3 0x28077e4d in __terminate () at HtHTTPBasic.cc:33 > #4 0x280780c3 in __sjthrow () at HtHTTPBasic.cc:33 > #5 0x28077138 in __builtin_vec_new () at HtHTTPBasic.cc:33 So, this says the abort is caused by a builting "new" operation, almost certainly because it ran out of virtual memory. > #6 0x280e7e04 in WordDBCompress::Uncompress (this=0x9089050, > inbuff=0x28047000 "\004", inbuff_length=1016, outbuff=0x8417220 "\001", > outbuff_length=8192) > at WordDBPage.h:490 > #7 0x280e7783 in WordDBCompress_uncompress_c (inbuff=0x28047000 "\004", > inbuff_length=1016, outbuff=0x8417220 "\001", outbuff_length=8192, > user_data=0x9089050) at WordDBCompress.cc:48 > #8 0x28193840 in CDB___memp_cmpr_read (dbmfp=0x80526c0, bhp=0x84171e8, > db_io=0xbfbff1f4, niop=0xbfbff1f0) at mp_cmpr.c:288 > #9 0x281935b6 in CDB___memp_cmpr (dbmfp=0x80526c0, bhp=0x84171e8, > db_io=0xbfbff1f4, flag=1, niop=0xbfbff1f0) at mp_cmpr.c:139 > #10 0x28192cbd in CDB___memp_pgread (dbmfp=0x80526c0, bhp=0x84171e8, > can_create=0) at mp_bh.c:212 > #11 0x28194c27 in CDB_memp_fget (dbmfp=0x80526c0, pgnoaddr=0xbfbff2b8, > flags=0, addrp=0x806fb84) at mp_fget.c:353 > #12 0x2816059e in CDB___bam_c_next (dbc=0x806fd00, initial_move=1) at > bt_cursor.c:1289 > #13 0x2815f2c1 in CDB___bam_c_get (dbc_orig=0x806fa00, key=0xbfbff454, > data=0xbfbff43c, flags=17) at bt_cursor.c:636 > #14 0x280e651d in WordCursor::WalkNextStep (this=0x806fc00) at WordDB.h:271 > #15 0x280e644e in WordCursor::WalkNext (this=0x806fc00) at WordCursor.cc:245 > #16 0x280e5ad9 in WordCursor::Walk (this=0x806fc00) at WordCursor.cc:123 > #17 0x280f7fee in WordList::Collect (this=0xbfbff7a0, wordRef=@0xbfbff530) > at WordList.cc:201 > #18 0x280f7e13 in WordList::WordRefs (this=0xbfbff7a0) at WordList.cc:193 And this says the problem occurred when htmerge was trying to load in the WordRefs list. That's exactly the problem Geoff and I were discussing. htmerge tries to load the entire word database, uncompressed, into virtual memory. Doesn't work if the database is too big to fit in memory. > #19 0x804a4be in mergeDB () at htmerge.cc:323 > #20 0x8049a70 in main (ac=8, av=0xbfbffb20) at htmerge.cc:174 > #21 0x8049561 in _start () > ------------------------------- The fix is to do as Lorenzo Campedelli's patch to 3.2.0b2 did (http://www.opdenbrouw.nl/htdig/maindocs/patches/3.2.0b2/htmerge.0), and make htmerge walk through the database one item at a time, instead of collecting everything into a huge list. The problem is the API for walking changed between 3.2.0b2 and 3.2.0b4, and will likely change at least once more before 3.2.0b4 is finally released, so anything of this sort would likely be a temporary measure. Still, it probably wouldn't be too difficult to figure out the API changes and adapt Lorenzo's patch. I just don't have the time to dig into it right now. -- Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil Dept. Physiology, U. of Manitoba Phone: (204)789-3766 Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930 _______________________________________________ htdig-general mailing list <[EMAIL PROTECTED]> To unsubscribe, send a message to <[EMAIL PROTECTED]> with a subject of unsubscribe FAQ: http://htdig.sourceforge.net/FAQ.html
