What steps will reproduce the problem? 1. Run 'mu find to:mbinder flag:attach' (or any other 'mu find' command 2. Process will die with SIGSEGV

What is the expected output? What do you see instead?

Expect to see results; get coredump instead.

What version of the product are you using? On what operating system?

mu 0.9.9.5 built from source on Ubuntu 12.04

Please provide any additional information below.

Failure and backtrace:

(gdb) run Starting program: /usr/local/bin/mu find to:mbinder flag:attach [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault. output_plain_fields (color=1, fields=<optimized out>, msg=0x682a00, threads=<optimized out>) at mu-cmd-find.c:434 434 for (myfields = fields, nonempty = 0; *myfields; ++myfields) { (gdb) bt

0 output_plain_fields (color=1, fields=<optimized out>, msg=0x682a00,

threads=<optimized out>) at mu-cmd-find.c:434

1 output_plain (msg=0x682a00, iter=<optimized out>, opts=0x63de40,

err=<optimized out>) at mu-cmd-find.c:465

2 0x000000000040c930 in output_query_results (err=0x7fffffffe968,

opts=0x63de40, iter=0x670300) at mu-cmd-find.c:583

3 process_query (query=<optimized out>, err=0x7fffffffe968, opts=0x63de40,

xapian=0x64f630) at mu-cmd-find.c:612

4 execute_find (err=0x7fffffffe968, opts=0x63de40, store=<optimized out>)

at mu-cmd-find.c:639

5 mu_cmd_find (store=<optimized out>, opts=0x63de40, err=0x7fffffffe968)

at mu-cmd-find.c:723

6 0x000000000040fa8f in with_store (func=0x40c370 <mu_cmd_find>,

opts=0x63de40, read_only=<optimized out>, err=0x7fffffffe968)
at mu-cmd.c:559

7 0x0000000000409dbe in main (argc=1, argv=0x7fffffffea68) at mu.cc:113

(gdb)

Hmmm, cannot reproduce this with the latest (git), but then again the query does not mach anyone in my case. The function in the last frame has not changed though.

Some questions: - does it happen for all (or similar) queries? - can you make coredump with debug symbols (ie. ./configure CFLAGS="-O0 -ggdb"; make clean; make)

Thanks!

It was crashing on all 'find' commands.

The version of 'mu' rebuilt with the additional CFLAGS as above doesn't crash.

Guess I can live with the additional inefficiency - but I'm happy to do more if you'd like to continue debugging.

Thanks! -- Jon

Hmmm... if it breaks for all queries, there's clearly something wrong... can you run with valgrind, if it's not too inconvenient?

Some more data: setting CFLAGS to '-g' (or --ggdb, or -O0, or -O1) will result in a binary that doesn't segfault. So it's not possible to build a binary that plays nice with valgrind but still has the problem.

I've manually confirmed, setting CFLAGS to '-O2' is sufficient to cause core dumps. This is repeatable on my system. But -- ah-ha -- I can cause core dumps with '-g -O2'. I know -O2 @#@$%s up line numbers for valgrind, but here's the valgrind output when built with '-g -O2':

jlasser@spooky:/usr/local/src/mu-0.9.9.5$ valgrind mu/mu find abcd==21472== Memcheck, a memory error detector ==21472== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==21472== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==21472== Command: mu/mu find abcd ==21472== ==21472== Invalid read of size 1 ==21472== at 0x40C098: output_plain (mu-cmd-find.c:434) ==21472== by 0x40C92F: mu_cmd_find (mu-cmd-find.c:583) ==21472== by 0x40FA8E: with_store (mu-cmd.c:559) ==21472== by 0x409DBD: main (mu.cc:113) ==21472== Address 0x1 is not stack'd, malloc'd or (recently) free'd ==21472== ==21472== ==21472== Process terminating with default action of signal 11 (SIGSEGV) ==21472== Access not within mapped region at address 0x1 ==21472== at 0x40C098: output_plain (mu-cmd-find.c:434) ==21472== by 0x40C92F: mu_cmd_find (mu-cmd-find.c:583) ==21472== by 0x40FA8E: with_store (mu-cmd.c:559) ==21472== by 0x409DBD: main (mu.cc:113) ==21472== If you believe this happened as a result of a stack ==21472== overflow in your program's main thread (unlikely but ==21472== possible), you can try to increase the size of the ==21472== main thread stack using the --main-stacksize= flag. ==21472== The main thread stack size used in this run was 8388608. Wed Dec 31 16:00:00 1969==21472== ==21472== HEAP SUMMARY: ==21472== in use at exit: 22,653,900 bytes in 903 blocks ==21472== total heap usage: 2,542 allocs, 1,639 frees, 46,244,609 bytes allocated ==21472== ==21472== LEAK SUMMARY: ==21472== definitely lost: 0 bytes in 0 blocks ==21472== indirectly lost: 0 bytes in 0 blocks ==21472== possibly lost: 14,913 bytes in 206 blocks ==21472== still reachable: 22,638,987 bytes in 697 blocks ==21472== suppressed: 0 bytes in 0 blocks ==21472== Rerun with --leak-check=full to see details of leaked memory ==21472== ==21472== For counts of detected and suppressed errors, rerun with: -v ==21472== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Segmentation fault (core dumped) jlasser@spooky:/usr/local/src/mu-0.9.9.5$

I've made some fixes for what seemed a bsd-specific issue (see issue #75), but it may apply here as well... can you try with the latest git version? thanks.

Still segfaults, but not when built with a different optimization level.

Hmmm... would you be able to get a fresh backtrace? Thanks.

jlasser@spooky:~/src/mu$ gdb mu/mu GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: http://bugs.launchpad.net/gdb-linaro/... Reading symbols from /mnt/local/jlasser/src/mu/mu/mu...done. (gdb) run find to:mbinder flag:attach Starting program: /mnt/local/jlasser/src/mu/mu/mu find to:mbinder flag:attach [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault. output_plain_fields (color=1, fields=, msg=0x683a00, threads=) at mu-cmd-find.c:461 461 for (myfields = fields, nonempty = 0; *myfields; ++myfields) { (gdb) bt

0 output_plain_fields (color=1, fields=, msg=0x683a00,

threads=<optimized out>) at mu-cmd-find.c:461

1 output_plain (msg=0x683a00, iter=, opts=0x63ee60,

err=<optimized out>) at mu-cmd-find.c:492

2 0x000000000040cbc0 in output_query_results (err=0x7fffffffe958,

opts=0x63ee60, iter=0x671330) at mu-cmd-find.c:610

3 process_query (query=, err=0x7fffffffe958, opts=0x63ee60,

xapian=0x650660) at mu-cmd-find.c:639

4 execute_find (err=0x7fffffffe958, opts=0x63ee60, store=)

at mu-cmd-find.c:666

5 mu_cmd_find (store=, opts=0x63ee60, err=0x7fffffffe958)

at mu-cmd-find.c:750

6 0x000000000040fe2f in with_store (func=0x40c600 ,

opts=0x63ee60, read_only=<optimized out>, err=0x7fffffffe958)
at mu-cmd.c:547

7 0x0000000000409eb2 in main (argc=1, argv=0x7fffffffea58) at mu.cc:120

(gdb)

Hmmm, haven't been able to reproduce this at all. I've made some minor change that may help, but it's hard to say...

Synced up via git, rebuilt. Same problem. Anything I can provide from GDB to help debug this?

I've tried once more with different with both gcc and clang, and various optimization-levels, but I can't to reproduce this, and valgrind doesn't show anything either...

It seems the fields-param is somehow corrupted... does it still happen when you give some explicit value for fields? (e.g., --fields=s)?

Also, the very latest git changes things for parameters a little bit; perhaps this helps.

Argh. I've done some more looking here.

I built a fresh Ubuntu VM, and the problem doesn't occur there -- even with the same binary that segfaults on the host system. So clearly there's a problem elsewhere on the box with libraries, though I have no idea how to track that down.

Stranger still: if (on the box where it does segfault) I run 'mu find whatever | cat', it doesn't segfault -- but it produces empty results, even in cases where my non-O2 binary produces extensive results.

Additional: "-g -O2 -fno-caller-saves" works, so I'm closing in on this.

I can now reproduce this on my Ubuntu 12.04 VM. All that's necessary is -fcaller-saves and setting the locale to C. (so, on the CLI, 'export LANG=C' and run a binary built with -O2 to induce the failure.