--- Alexander Barkov [EMAIL PROTECTED] wrote:
No, unfortunately we haven't found bug yet :-(
Your last debug information should help.
it appears i was right about size_t causing the problem on Alpha.
Again, sizeof(size_t) on the Alpha is 8, while on i386 it's 4. i'm not
exactly sure what
Thanks for debugging! This will help us.
Caffeinate The World wrote:
it put in a printf to help track down the problem:
for(t=1;tcount+1;t++){
/* Debug to test array out of bound */
printf("Count:%4d, headerntables:%4d,
Array Index
further testing shows that it's because size_t is
unsigned int on intel, but on the alpha it's unsigned
long. i'm on the alpha. it's understandable why we'd
overun the array buffer since i'd have on huge number
on the alpha.
--- Alexander Barkov [EMAIL PROTECTED] wrote:
Thanks for debugging!
it put in a printf to help track down the problem:
for(t=1;tcount+1;t++){
/* Debug to test array out of bound */
printf("Count:%4d, headerntables:%4d,
Array Index t:%4d\n",count,header.ntables,t);
if((logwords[t-1].wrd_id!=logwords[t].wrd_id)||
--- Alexander Barkov [EMAIL PROTECTED] wrote:
We are trying to discover this bug now.
i've not had 8 files that made splitter core dump. all
of them at 'var/tree/77/C/77C3'
i hope that was more detail for you. there is a
pattern there.
Caffeinate The World wrote:
mnogosearch
mnogosearch 3.1.9-pre13, pgsql 7.1-current,
netbsd/alpha 1.5.1-current
running cachemode. i've been indexing and splitter-ing
just fine. 'til today when after an overnight of
indexers running and gathering up a log file of over
31 MB, cachelogd automatically started a new log file.
i ran
--- Caffeinate The World [EMAIL PROTECTED]
wrote:
mnogosearch 3.1.9-pre13, pgsql 7.1-current,
netbsd/alpha 1.5.1-current
running cachemode. i've been indexing and
splitter-ing
just fine. 'til today when after an overnight of
indexers running and gathering up a log file of
over
31 MB,
