On Wed, 2006-08-02 at 08:41 +0900, David Balmain wrote:
> This would usually be enough but there seems to be some weird stuff
> happening there. For example, argv = NULL on line #18 which doesn't
> seem possible to me. On line #14 iw gets a strange value but then it
> gets restored on line #13. Anyway, I think the error is occurring
> higher up on the stack so maybe it doesn't matter. I'll keep trying to
> work out what is going on but it'd be a lot easier if you could give
> me something I could run here to reproduce the error.
I have a standalone test case that blows up predictably every time.
Since it involves some internal data I have to clear it with the powers
that be. Shouldn't be a problem. As soon as that's done I'll mail it
privately to you. Shouldn't take too long.
Meanwhile here's a different backtrace:
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d469a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d482b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7d7a87a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7d80fd4 in malloc_usable_size ()
from /lib/tls/i686/cmov/libc.so.6
#5 0xb7d8134a in free () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7b8dcae in tb_destroy (tb=0x0) at term.c:91
#7 0xb7b8dffc in te_destroy (te=0x49) at term.c:214
#8 0xb7b8e345 in ste_close (te=0x821b978) at term.c:326
#9 0xb7b86b2b in smi_destroy (smi=0x823e670) at index_rw.c:1984
#10 0xb7b88661 in sm_merge_term_infos (sm=0x80d2ba0) at index_rw.c:2282
#11 0xb7b88827 in sm_merge_terms (sm=0x80d2ba0) at index_rw.c:2314
#12 0xb7b88fc2 in sm_merge (sm=0x80d2ba0) at index_rw.c:2384
#13 0xb7b8906c in iw_merge_segments_with_max (iw=0x80a8450,
min_segment=12,
max_segment=17) at index_rw.c:829
#14 0xb7b892a7 in iw_merge_segments (iw=0x6, min_segment=0) at
index_rw.c:860
#15 0xb7b89311 in iw_flush_ram_segments (iw=0x80a8450) at index_rw.c:918
#16 0xb7b89376 in iw_close (iw=0x80a8450) at index_rw.c:965
#17 0xb7b9ab93 in index_destroy (self=0x80fd6c0) at ind.c:90
#18 0xb7b7679b in frt_ind_free (p=0x80fd6c0) at r_search.c:1677
#19 0xb7ef08de in rb_gc_call_finalizer_at_exit ()
from /usr/lib/libruby1.8.so.1.8
#20 0xb7ed28be in is_ruby_native_thread ()
from /usr/lib/libruby1.8.so.1.8
#21 0xb7eea0d3 in ruby_cleanup () from /usr/lib/libruby1.8.so.1.8
#22 0xb7eea1b3 in ruby_stop () from /usr/lib/libruby1.8.so.1.8
#23 0xb7eea84e in ruby_run () from /usr/lib/libruby1.8.so.1.8
#24 0x080485dc in main ()
Looks much cleaner since it's actually a full one while the other was
full of ruby's thread handling that I truncated. Probably because it was
running inside a full rails environment. This time I ripped everything
out and it's just ferret calls.
Pedro.
_______________________________________________
Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk
