After looking for a suitable place to post lengthy log files, I filed https://bugs.kde.org/show_bug.cgi?id=377006 in valgrind bugzilla with a set of log files.
Sorry, I have forgotten to post a notice to this mailing list. If someone can figure out a possible way to proceed with debugging, I would appreciate to hear it. TIA On 2017/02/22 2:25, ISHIKAWA,chiaki wrote: > 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
