Hi!
Can you guys give us a log file produced by splitter -p which caused
crash? We can't reproduce crash :-(
Caffeinate The World wrote:
>
> i reported this problems a while back. i believe it's being worked on.
> atleast the recently found the bug why it wasn't splitting out to FFF.
> the seg fault happens during the splitter process and not index. i've
> been splitter when the logs are at about < 2 MB and i've not had
> splitter core dump on me yet. but before when i let the log file build
> up to about 15 to 30 MB, i had that core dump problem.
>
> i hope this will be resolved soon because it's a pain in the behind.
> ;-(
> --- Zenon Panoussis <[EMAIL PROTECTED]> wrote:
> > Author: Zenon Panoussis
> > Email: [EMAIL PROTECTED]
> > Message:
> > RH Linux 7.0, search 3.1.9, MySQL 3.23.29, cache mode, with the
> > new patches for cache.c and sql.c.
> >
> > It happens all the time. It started happening when "maximum size"
> > 31 MB log files were indexed, but by now it happens on any indexing,
> > no matter how big or small the log file, as if the database somehow
> > was corrupt:
> >
> > 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
> >
> > For the same log file it always crashes at the same index file
> > (e.g. every time I try to reindex 12345678.log it will crash
> > at tree/12/3/4567000). If I delete the log file and start again
> > with a new log file, it will crash at a different place, but it
> > will still be consistent in crashing at the same place every time.
> >
> > And the backtrace:
> >
> > # gdb splitter core
> > GNU gdb 5.0
> > [...]
> > This GDB was configured as "i386-redhat-linux"...
> > Core was generated by `/usr/local/mnogo319/sbin/splitter'.
> > Program terminated with signal 11, Segmentation fault.
> > Reading symbols from /usr/lib/mysql/libmysqlclient.so.10...done.
> > Loaded symbols for /usr/lib/mysql/libmysqlclient.so.10
> > Reading symbols from /lib/libm.so.6...done.
> > Loaded symbols for /lib/libm.so.6
> > Reading symbols from /usr/lib/libz.so.1...done.
> > Loaded symbols for /usr/lib/libz.so.1
> > Reading symbols from /lib/libc.so.6...done.
> > Loaded symbols for /lib/libc.so.6
> > Reading symbols from /lib/libcrypt.so.1...done.
> > Loaded symbols for /lib/libcrypt.so.1
> > Reading symbols from /lib/libnsl.so.1...done.
> > Loaded symbols for /lib/libnsl.so.1
> > Reading symbols from /lib/ld-linux.so.2...done.
> > Loaded symbols for /lib/ld-linux.so.2
> > #0 0x8059061 in UdmSplitCacheLog (log=300) at cache.c:552
> > 552
> > logwords[count+j].wrd_id=table[w].wrd_id;
> >
> > (gdb) backtrace
> > #0 0x8059061 in UdmSplitCacheLog (log=300) at cache.c:552
> > #1 0x8049e89 in main (argc=1, argv=0xbffffa94) at splitter.c:70
> > #2 0x4009bbfc in __libc_start_main (main=0x8049d80 <main>, argc=1,
> > ubp_av=0xbffffa94,
> > init=0x80495bc <_init>, fini=0x8065b7c <_fini>,
> > rtld_fini=0x4000d674 <_dl_fini>, stack_end=0xbffffa8c)
> > at ../sysdeps/generic/libc-start.c:118
> >
> > Since 3.1.10 is coming out today, I'll try it and see if things
> > work better. If not, I'll post more bad news later ;)
______________
If you want to unsubscribe send "unsubscribe udmsearch"
to [EMAIL PROTECTED]
