Sorry for top-posting, but thank you for the suggestions. So far, I figured out that the maps are different under 3.19.5, 4.7.0.1, and 4.9.6 versions of linux kernel.
Also, I have figured out the SIGSEGV problem is timing-related/race under 4.7.0.1 (Worst bug in terms of reproducibility). If managed to attach to the thunderbird binary executing under valgrind using --vgdb=y and --vgdb-error=0 and single step (or step over functions) through thunderbird to figure out what kind of thunderbird behavior may trigger valgrind problem. Then I noticed the SIGSEGV did not occur when I stepped through the code (over the fork) while if I simply run the thunderbird code by "cont" all the way, SIGSEGV occurs :-( To sum up, under 4.7.0.1, the SIGSEGV seems to occur near the fork() system call. Thunderbird invokes a small glxtest program which checks for the graphics driver info (for debugging?). And fork() is reached before SIGSEGV is observed under 4.7.0.1. [I thought that I was homing on a possible bug.] But under 4.9.6, the SIGSEGV seems to occur way before this fork() is executed and it is very difficult yet to figure out where the SIGSEGV occurs. Under 3.19.5, thunderbird runs under valgrind just fine. From the way it goes, I will be able to post the logs with some results from additional probes at the beginning of next week. On 2017/02/20 8:30, John Reiser wrote: > On 02/18/2017 11:38 PM, ISHIKAWA,chiaki wrote: >> BTW, DOES ANYONE HAVE A GOOD IDEA ABOUT HOW TO CAPTURE the mapped >> file, etc WHEN SIGSEGV happens? It is very dynamic and by the time I >> am ready to type in shell commands, the child binary that experienced >> it may be gone. Yes, I have not been able to figure out exactly which >> process under the test >> suite setup started by thunderbird (under valgrind) is experiencing a >> difficulty. >> I guess some clever hacking via gdb gets me started there? >> BTW, valgrind's --gdb-* options are meant to debug the target under >> valgrind, NOT the segfault of valgrind itself, correct? >> [And the whole thing including valgrind works under kernel 3.19.5 and >> not under later kernel drives me crasy.] > > This gdb command will stop execution and print a message when SIGSEGV > happens: > (gdb) handle SIGSEGV stop print > When the SIGSEGV happens then you will have to focus keyboard input to > that process. > (The above 'handle' command is the default anyway, so if the automation > for your > test harness snatches control, then you still might not get a chance for > manual input.) > There is no way to ask of gdb, "Please run these commands upon SIGSEGV." > > You can write a script for the entire input to gdb: gdb -batch -x script > -e executable > (beware: it is very brittle) but gdb cannot switch its input stream > (such as back and forth between the script and the terminal) > while it is running. "gdb -batch -x script -e executable" might be your > best option, > but it will take some patience. There is no way for the script to > check that gdb is waiting for input after SIGSEGV, so you just have to > assume > that the SIGSEGV is going to happen after your 'run' command in the input. > > Yes, valgrind's --gdb-* options are for debugging the target under > valgrind, > and are NOT for debugging valgrind itself. > > > If you run "strace -f -o strace.out -e trace=execve valgrind > --trace-children=yes ..." > then the output in strace.out will tell you which process receives the > SIGSEGV. > The "-e trace=execve" is a filter which restricts tracing to execve only; > otherwise the output will be very long because it contains every system > call > for every process. > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
