--- Caffeinate The World <[EMAIL PROTECTED]> wrote:
> that was a little premature on my part. it did core dump again at 77C
> when i tried to split another log file. argh.

it should be noted that i used log files from 3.1.9pre13. these log
files were processed with cachelogd where i hadn't changed size_t to
"unsigned int" yet. in which case it could have written the "wrong"
record length or something.

the very first batch i processed with "new" indexer (u_int32_t) were
created with cachelogd (with size_t changed to unsigned int). that
batch went fine. no core. then i processed the old 31 MB log from a
cachelogd where it was still using size_t. this 31 mb log file also was
written ok too. but when i processed another "older" log file, that's
when it core again at 77C. it could be the older log files where
cachelogd had size_t are causing problems.

> --- Caffeinate The World <[EMAIL PROTECTED]> wrote:
> > overnight, the "new splitter" using "u_int32_t" was able to split a
> > log
> > file around 31MB. this is the first time i've seen it able to index
> > the
> > log at 77C. can you verify that linux and such have "u_int32_t"? if
> > it's does, i'll submit my patch. this should fix the problem with
> the
> > alpha. also the patch should enable NetBSD to compile cleanly cause
> > we
> > don't have native threads yet.
> > 
> > i'll do some more tests before i can make this official.
> > 
> > --- Caffeinate The World <[EMAIL PROTECTED]> wrote:
> > > just a quick note, i changed all occurances of "size_t" in
> cache.c
> > > into
> > > "u_int32_t" and recompiled splitter. it seems as though it
> doesn't
> > > core dump on
> > > log files like before. note that i had to do "splitter -p" to get
> > new
> > > files in
> > > ./splitter and then run "splitter". i've only been able to test
> > this
> > > on a small
> > > set of logs. related to this, i also changed "size_t" in
> > cachelogd.c
> > > to
> > > "unsigned int". for some reason if i changed it to "u_int32_t" my
> > > server ran at
> > > a very hight load.. usually it sits at around 1. but if i ran
> > > cachelogd with
> > > "u_int32_t" changes, it ran at over 30 for system load. scary.
> > > 
> > > 
> > > --- Caffeinate The World <[EMAIL PROTECTED]> wrote:
> > > > NetBSD/Alpha (64bit). I reported this a while back for
> > 3.1.9pre13.
> > > Looks like
> > > > it was not fixed for 3.1.9. I'm using cache mode.
> > > > 
> > > > # gdb /usr/local/install/mnogosearch-3.1.9/sbin/splitter
> > > > GNU gdb 4.17
> > > > Copyright 1998 Free Software Foundation, Inc.
> > > > GDB is free software, covered by the GNU General Public
> License,
> > > and you are
> > > > welcome to change it and/or distribute copies of it under
> certain
> > > conditions.
> > > > Type "show copying" to see the conditions.
> > > > There is absolutely no warranty for GDB.  Type "show warranty"
> > for
> > > details.
> > > > This GDB was configured as "alpha--netbsd"...
> > > > (gdb) run -f 77c -t 77c
> > > > Starting program:
> > > /usr/local/install/mnogosearch-3.1.9/sbin/splitter -f 77c
> > > > -t
> > > > 77c
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C0B000
> old: 
> > 
> > > 0 new:   1
> > > > total:   1
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C0C000
> old: 
> > 
> > > 0 new:   1
> > > > total:   1
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C15000
> old: 
> > 
> > > 0 new:   6
> > > > total:   6
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C1C000
> old: 
> > 
> > > 0 new:   1
> > > > total:   1
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C1F000
> old: 
> > 
> > > 0 new:   1
> > > > total:   1
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C23000
> old: 
> > 
> > > 0 new:   1
> > > > total:   1
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C2B000
> old: 
> > 
> > > 0 new:   2
> > > > total:   2
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C2E000
> old: 
> > 
> > > 0 new:   1
> > > > total:   1
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C2F000
> old: 
> > 
> > > 0 new:   1
> > > > total:   1
> > > > /usr/local/install/mnogosearch-3.1.9/var/tree/77/C/77C30000
> old: 
> > 
> > > 0
> > > > new:36482
> > > > total:36482
> > > > 
> > > > Program received signal SIGSEGV, Segmentation fault.
> > > > 0x1200182b0 in UdmSplitCacheLog (log=79072) at cache.c:601
> > > > 601                                                            
> > > > table[header.ntables].wrd_id=logw
> > > > ords[t-1].wrd_id;
> > > > (gdb) bt
> > > > #0  0x1200182b0 in UdmSplitCacheLog (log=79072) at cache.c:601
> > > > #1  0x120002ae0 in main (argc=1917, argv=0x1fffff8c0) at
> > > splitter.c:70
> > > > warning: Hit heuristic-fence-post without finding
> > > > warning: enclosing function for address 0x1400013550
> > > > This warning occurs if you are debugging a function without any
> > > symbols
> > > > (for example, in a stripped executable).  In that case, you may
> > > wish to
> > > > increase the size of the search with the `set
> > heuristic-fence-post'
> > > command.
> > > > 
> > > > Otherwise, you told GDB there was a function where there isn't
> > one,
> > > or
> > > > (more likely) you have encountered a bug in GDB.
> > > > (gdb) l
> > > > 596                                            
> > > logwords[count].weight=0;
> > > > 597
> > > > 598                                            
> > > for(t=1;t<count+1;t++){
> > > > 599                                                    
> > > > if((logwords[t-1].wrd_id!=logwords[t].wrd
> > > > _id)||
> > > > 600                                                       
> > > > (logwords[t-1].weight!=logwords[t].wei
> > > > ght)){
> > > > 601                                                            
> > > > table[header.ntables].wrd_id=logw
> > > > ords[t-1].wrd_id;
> > > > 602                                                            
> > > > table[header.ntables].weight=logw
> > > > ords[t-1].weight;
> > > > 603                                                            
> > > > table[header.ntables].pos=pos;
> > > > 604                                                            
> > > > table[header.ntables].len=t*sizeo
> > > > f(UDM_CACHEWORD)-pos;
> > > > 605                                                            
> > > > pos+=table[header.ntables].len;
> > > > (gdb)
> > > > 
> > > > __________________________________________________
> > > > Get personalized email addresses from Yahoo! Mail - only $35 
> > > > a year!  http://personal.mail.yahoo.com/
> > > > ______________
> > > > If you want to unsubscribe send "unsubscribe udmsearch"
> > > > to [EMAIL PROTECTED]
> > > > 
> > > 
> > > 
> > > __________________________________________________
> > > Get personalized email addresses from Yahoo! Mail - only $35 
> > > a year!  http://personal.mail.yahoo.com/
> > 
> > 
> > __________________________________________________
> > Get personalized email addresses from Yahoo! Mail - only $35 
> > a year!  http://personal.mail.yahoo.com/
> 
> 
> __________________________________________________
> Get personalized email addresses from Yahoo! Mail - only $35 
> a year!  http://personal.mail.yahoo.com/


__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/
______________
If you want to unsubscribe send "unsubscribe udmsearch"
to [EMAIL PROTECTED]

Reply via email to