On Mon, Jun 04, 2007 at 10:54:52AM +0200, Reuben Thomas wrote: > On Sat, 2 Jun 2007, Robert Millan wrote: > > >Package: zile > >Version: 2.2.31-1 > >Severity: grave > > > >If you edit the attached ca.po (obtained from totem svn) on an x86_64 > >system, > >and try to search something (in my test, "aaaa"), zile will crash. > > Could I have a gdb backtrace (and a valgrind trace if that works on > x86_64)?
gdb backtrace: #0 0x0000000000411aa2 in search_forward (startp=0x55e9a0, starto=0, s=0x55d7e1 "a", regexp=0) at search.c:94 #1 0x0000000000412379 in isearch (dir=1, regexp=0) at search.c:498 #2 0x0000000000405d39 in process_key (key=627) at bind.c:218 #3 0x000000000040ffd2 in main (argc=1, argv=<value optimized out>) at main.c:88 valgrind trace: ==27344== Memcheck, a memory error detector. ==27344== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==27344== Using LibVEX rev 1658, a library for dynamic binary translation. ==27344== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==27344== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==27344== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==27344== For more details, rerun with: -v ==27344== ==27344== Invalid read of size 1 ==27344== at 0x411AA2: search_forward (search.c:94) ==27344== by 0x412378: isearch (search.c:498) ==27344== by 0x405D38: process_key (bind.c:218) ==27344== by 0x40FFD1: main (main.c:88) ==27344== Address 0x100521062 is not stack'd, malloc'd or (recently) free'd Zile crashed. Please send a bug report to <[EMAIL PROTECTED]>. Trying to save modified buffers (if any)... ==27344== ==27344== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1) ==27344== malloc/free: in use at exit: 444,572 bytes in 7,903 blocks. ==27344== malloc/free: 11,945 allocs, 4,042 frees, 598,242 bytes allocated. ==27344== For counts of detected errors, rerun with: -v ==27344== searching for pointers to 7,903 not-freed blocks. ==27344== checked 572,520 bytes. ==27344== ==27344== LEAK SUMMARY: ==27344== definitely lost: 0 bytes in 0 blocks. ==27344== possibly lost: 0 bytes in 0 blocks. ==27344== still reachable: 444,572 bytes in 7,903 blocks. ==27344== suppressed: 0 bytes in 0 blocks. ==27344== Reachable blocks (those to which a pointer was found) are not shown. ==27344== To see them, rerun with: --show-reachable=yes > I don't have an x86_64 system, and I can't reproduce the bug on my > i386 system, nor does valgrinding while trying to repro it give any errors. I can try more things if you like. Also note that qemu-system-x86_64 should work for testing (and its speed is usable nowadays). > I'd be grateful for an exact sequence of operations too (e.g. are you > talking about isearch-forward (which for me fails on the second "a") or > search-forward? Sorry, I don't really know. The default when typing ctrl-s. Thank you, -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
