Re: [Valgrind-users] Problem of running mozilla thunderbird under valgrind on Debian GNU/Linux 4.x kernel.

[ISHIKAWA,chiaki <ish...@yk...>]

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