in my tests your 3 little files wouldn't make a difference. he would
have to run splitter -p and splitter on all the files starting from the
first original RAW file, including all the 31 MB file. i believe in my
case it was the original 31mb file which caused the problem.
while processing the first 31mb file, it didn't core dump, but all the
preceeding files did cause core dumps at unpredictable times, but often
at the same location initially (i.e. 77C3000...)
therefore, in order to recreate the scenario, one would have to start
from the first raw file. i've tar-ed up such a series of file for Alex.
perhaps he'll be able to find out why. my hypothesis is an array or
buffer overflow in splitter.c.
--- Zenon Panoussis <[EMAIL PROTECTED]> wrote:
>
>
> Alexander Barkov skrev:
> >
>
> > Can you guys give us a log file produced by splitter -p which
> caused
> > crash? We can't reproduce crash :-(
>
> Huh? splitter doesn't accept the -v5 argument, so it won't give
> more detailed logs than the normal ones. The only log I had, that
> to stdout, is the one I included with my first posting in this
> thread:
>
> Delete from cache-file /var/mnogo319/tree/12/B/12BFD000
> /var/mnogo319/tree/12/C/12C10000 old: 69 new: 1 total: 70
> ./run-splitter: line 118: 18790 Segmentation fault (core
> dumped) $SPLITTER
>
> Until this point everything was normal.
>
> Anyway, as I said, I strongly suspect corruption in the word
> database. On a previous occasion when this happened, I deleted
> the entire tree/* directory structure and started all over again.
> Splitter worked like a dream with both small and big log files
> until one of the following occured:
>
> 1. I stopped indexer with ^C and then run splitter
> or
> 2. Splitter had to work itself through some 31 MB files. (These
> files are not all the same size; they tend to get slightly
> bigger the more they are, i.e. something like this:
> 00000001.log 31.500.000 bytes
> 00000002.log 31.550.000 bytes
> 00000003.log 31.580.000 bytes
> sort of).
>
> Unfortunately I haven't been making notes, so I can't tell for
> sure which one of these two things happened before things stopped
> working.
>
> I tried splitter again today with ./splitter >splitter.log . It
> went in a very normal way *almost* as far as yesterday, and then
> hang so badly that not even kill -9 could kill it. The log of
> this run looks like
>
> <snip normal operation>
> Delete from cache-file /var/mnogo319/tree/12/B/12B27000
> Delete from cache-file /var/mnogo319/tree/12/B/12B2D000
> Delete from cache-file /var/mnogo319/tree/12/B/12B30000
> Delete from cache-file /var/mnogo319/tree/12/B/12B31000
> Delete from cache-file /var/mnogo319/tree/12/B/12B3
>
> I am attaching the three files that could be involved,
> namely tree/12/B/12B31000, 12B32000 and 12B35000.
>
>
> I'll install 3.1.10 now, try it on the old word database and see
> what it does. If it doesn't work, I'll remove the word database
> and start again from scratch. I'll try to make detailed notes this
> time and report back.
>
> Z
>
>
> --
> oracle@everywhere: The ephemeral source of the eternal truth...
> ATTACHMENT part 2 application/x-gzip name=wordfiles.tar.gz
__________________________________________________
Do You Yahoo!?
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]
