mu find coredump

[GoogleCodeExporter]

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) 

Original issue reported on code.google.com by jon.las...@gmail.com on 14 Aug 2013 at 6:06

[GoogleCodeExporter]

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!

Original comment by digg...@gmail.com on 14 Aug 2013 at 6:37

[GoogleCodeExporter]

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

Original comment by jon.las...@gmail.com on 14 Aug 2013 at 6:51

[GoogleCodeExporter]

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

Original comment by digg...@gmail.com on 16 Aug 2013 at 5:07

[GoogleCodeExporter]

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$

Original comment by jon.las...@gmail.com on 16 Aug 2013 at 5:23

[GoogleCodeExporter]

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.

Original comment by digg...@gmail.com on 7 Sep 2013 at 3:46

[GoogleCodeExporter]

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

Original comment by jon.las...@gmail.com on 9 Sep 2013 at 5:14

[GoogleCodeExporter]

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

Original comment by digg...@gmail.com on 9 Sep 2013 at 5:23

[GoogleCodeExporter]

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=<optimized out>, msg=0x683a00, 
    threads=<optimized out>) at mu-cmd-find.c:461
461     for (myfields = fields, nonempty = 0; *myfields; ++myfields) {
(gdb) bt
#0  output_plain_fields (color=1, fields=<optimized out>, msg=0x683a00, 
    threads=<optimized out>) at mu-cmd-find.c:461
#1  output_plain (msg=0x683a00, iter=<optimized out>, 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=<optimized out>, err=0x7fffffffe958, opts=0x63ee60, 
    xapian=0x650660) at mu-cmd-find.c:639
#4  execute_find (err=0x7fffffffe958, opts=0x63ee60, store=<optimized out>)
    at mu-cmd-find.c:666
#5  mu_cmd_find (store=<optimized out>, opts=0x63ee60, err=0x7fffffffe958)
    at mu-cmd-find.c:750
#6  0x000000000040fe2f in with_store (func=0x40c600 <mu_cmd_find>, 
    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) 

Original comment by jon.las...@gmail.com on 9 Sep 2013 at 5:34

[GoogleCodeExporter]

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...

Original comment by digg...@gmail.com on 21 Dec 2013 at 6:27

[GoogleCodeExporter]

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

Original comment by jon.las...@gmail.com on 27 Dec 2013 at 6:30

[GoogleCodeExporter]

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.

Original comment by digg...@gmail.com on 29 Dec 2013 at 3:40

[GoogleCodeExporter]

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.

Original comment by jon.las...@gmail.com on 3 Jan 2014 at 10:51

[GoogleCodeExporter]

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

Original comment by jon.las...@gmail.com on 3 Jan 2014 at 11:35

[GoogleCodeExporter]

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.

Original comment by jon.las...@gmail.com on 3 Jan 2014 at 11:55