On 2017/02/16 1:50, ISHIKAWA,chiaki wrote:
> On 2017/02/15 23:32, Tom Hughes wrote:
>> On 15/02/17 13:34, ISHIKAWA,chiaki wrote:
>>
>>> When I tried to run mozilla thunderbird mail client, which I create
>>> under Debian GNU/Linux 64-bit,
>>> under valgrind, valgrind mysteriously crashed and gdb was not much help.
>>
>> Well valgrind almost never "mysteriously crashes".
>>
>> In fact it is usually very verbose when anything goes wrong.
>>
>
> Hi,
>
> Thank you for your comment.
>
> The above was what I thought back in 2015 and actually I exchanged a few
> e-mails with Julian Seward about the issue back then. But we gave up on it.
> Because the system printed out "Segmentation error" without a good trace
> of anything at all (!) (which was quite surprising): We traced signals,
> and stuff. Everything we could think of using various options passed to
> valgrind (and even traced the system calls valgrind was issuing using
> strace.).
>
>
>> So the first thing you should do is to tell us in detail exactly what it
>> said when it stopped.
>
> Since gdb and various traces invoked by the options passed to valgrind
> are useless (as in the case back in 2015),
> I traced the system calls issued by valgrind.
>
> There was a MMAP call before something went wrong and signal 11 was
> issued and then
> I saw SIGSEGV passed a dozen times or so, and voila. Segmentation error
> back at the shell level.
> gdb does not print anything useful at all...
>
>>
>>> This happened under the latest 4.8.x kernel which Debian distributed as
>>> part of its testing repository.
>>>
>>> I tried a few things but subsequently reverted to kernel 3.19.5.
>>> Now thunderbird under valgrind works (!).
>>
>> So most likely this is just a new system call that valgrind doesn't
>> handle or something, in which case valgrind will have reported all the
>> details needed to fix it when it stopped.
>
> That was what I (and Julian Seward) hoped back in 2015, but valgrind did
> not. From the debugging I did over the last few months, I figured the
> problem I face is indeed as perplexing as the case back in 2015 and I
> took the easy course now: I decided that trying to find out if there is
> ANYBODY who is using valgrind and running big program under it using
> Debian GNU/Linux official kernel is easier (which I doubt based on my
> experience). Also, Julian Seward back in 2015 mentioned valgrind could
> grok thunderbird under Fedora and thus I thought it would be easier to
> figure out if someone is running 64-bit thunderbird under CentOS or
> Fedora 64-bit and compare the config to figure out what is causing the
> problem under Debian's kernel.
>
> BTW, the following is is what I found back in 2015.
>
>
> ------------------------+----------------
> Kernel version | valgrind + C-C TB works or not
> ------------------------+----------------
> Debian 3.2.0...| works <--- base debian version for wheezy
> ------------------------+----------------
> self-compiled 3.9.0...| works
> ------------------------+----------------
> self-compiled 3.12.40 | works
> ------------------------+----------------
> self-compiled 3.13.11 | works
> ------------------------+----------------
>
> self-compiled 3.14.38 | ??? <--- pristine kernel hit the problem
> mentioned in the following patch and panicked. open source is
> wonderful when it works, but when it does not
> http://lkml.iu.edu/hypermail/linux/kernel/1407.3/04296.html
>
> ------------------------+----------------
> self-compiled 3.15.9 | ??? <--- vanilla kernel could not bring up X
> probably because the same reason above. X
> did not start in a few minutes, and so I gave up. I did not see the
> kernel panic, though.
>
> ------------------------+----------------
> Debian backport 3.16 ...| Segmentation fault! [Why? I have no idea.]
> ------------------------+----------------
>
> ------------------------+------------------
> Vanilla 3.19.5 | works (worked back in 2015 and now I have to
> revert to it...)
> ------------------------+------------------
>
> This time arouind, I tried to figure out if I could do something similar
> using the latest kernel 4.9.x (vanilla version), hoping it might make
> valgrind run thunderbird under it without segmentation error. But the
> very late kernel caused a problem of VirtualBox utility, such as
> graphics driver that supports dynamic resizing, not supporting the
> latest kernel as guest at all, and I had to give it up.
> (Yes, I am running Debian GNU/Linux inside VirtualBox.)
>
> Sorry, I was so tired of debugging and seeing that the current issue
> looked so much like the mysterious problem back in 2015, that I did not
> bother to pursue the issue in valgrind per se, but rather wanted to
> focus on kernel issue now.
>
> I am running the |make mozmill| test of thunderbird which now takes
> about 48 hours and once it is over, I will switch the kernel and gather
> the gdb stack trace (which is useless) when valgrind crashes, and
> also show the last part of strace (system call trace) which again is not
> very revealing.
>
> I am sure you will be perplexed why on earth valgrind is crashing when
> we try to run thunderbird underneath in Debian's kernel. [I *DID* notice
> that there are differences in Debian kernel that it enables stack
> protection, for starter. Not sure if it affects Valgrind operation.]
>
>
>>
>> Tom
>>
>
> TIA
Here are snipets from the log when valgrind could not run mozilla
thunderbird (which seems to spawn a few binaries during its life time
when it is invoked as part of |make mozmill| test suite.)
uname -a
Linux ip030 4.8.0-2-amd64 #1 SMP Debian 4.8.15-2 (2017-01-04) x86_64
GNU/Linux
ishikawa@ip030:/NREF-COMM-CENTRAL/comm-central$
---
run-valgrind (masquerading as thunderbird binary)
final command line is:
valgrind --trace-children=yes --smc-check=all-non-file
--gen-suppressions=all --malloc-fill=0xA5 --free-fill=0xC3
--leak-check=full --num-callers=50
--suppressions=$HOME/Dropbox/myown.sup
--suppressions=$HOME/Dropbox/myown32.sup --show-possibly-lost=no
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin -jsbridge 24242
-foreground -profile
/NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile
==3755== Memcheck, a memory error detector
==3755== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3755== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for
copyright info
==3755== Command: /NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin
-jsbridge 24242 -foreground -profile
/NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile
==3755==
==3755== Mismatched free() / delete / delete []
==3755== at 0x4C2CD3A: free (vg_replace_malloc.c:530)
==3755== by 0x13EE71B3: bool
google::protobuf::InsertIfNotPresent<std::map<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::pair<void const*,
int>, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > > >(std::map<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::pair<void const*,
int>, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > >*, std::map<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::pair<void const*,
int>, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > >::value_type::first_type const&,
std::map<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::pair<void const*, int>,
std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > >::value_type::second_type const&) (mozalloc.h:218)
==3755== by 0x13EE8827:
google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void
const*, int> >::AddFile(google::protobuf::FileDescriptorProto const&,
std::pair<void const*, int>) (descriptor_database.cc:56)
==3755== by 0x13EE8DDE:
google::protobuf::EncodedDescriptorDatabase::Add(void const*, int)
(descriptor_database.cc:313)
==3755== by 0x13EE8E4A:
google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*,
int) (descriptor.cc:1018)
==3755== by 0x13EE8EEE:
google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto()
(descriptor.pb.cc:711)
==3755== by 0x13EEB33A:
__static_initialization_and_destruction_0(int, int) (descriptor.pb.cc:762)
==3755== by 0x13EF879F:
_GLOBAL__sub_I_Unified_cpp_components_protobuf0.cpp (message.cc:358)
==3755== by 0x400F649: call_init.part.0 (dl-init.c:72)
==3755== by 0x400F75A: call_init (dl-init.c:30)
==3755== by 0x400F75A: _dl_init (dl-init.c:120)
==3755== by 0x4013CD7: dl_open_worker (dl-open.c:575)
==3755== by 0x400F4F3: _dl_catch_error (dl-error.c:187)
==3755== by 0x4013488: _dl_open (dl-open.c:660)
==3755== by 0x5055EE8: dlopen_doit (dlopen.c:66)
==3755== by 0x400F4F3: _dl_catch_error (dl-error.c:187)
==3755== by 0x5056520: _dlerror_run (dlerror.c:163)
==3755== by 0x5055F81: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==3755== by 0x123072: GetLibHandle(char const*) (nsXPCOMGlue.cpp:105)
==3755== by 0x1230FA: ReadDependentCB(char const*) (nsXPCOMGlue.cpp:157)
==3755== by 0x123337: XPCOMGlueLoad(char const*) (nsXPCOMGlue.cpp:333)
==3755== by 0x12347B: mozilla::GetBootstrap(char const*)
(nsXPCOMGlue.cpp:408)
==3755== by 0x10D406: InitXPCOMGlue(char const*) (nsMailApp.cpp:247)
==3755== by 0x10D7C4: main (nsMailApp.cpp:295)
==3755== Address 0x5f08f90 is 0 bytes inside a block of size 33 alloc'd
==3755== at 0x4C2C1EC: operator new(unsigned long)
(vg_replace_malloc.c:334)
==3755== by 0x113B8A: void std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::_M_construct<char*>(char*, char*, std::forward_iterator_tag)
(basic_string.tcc:219)
==3755== by 0x13EE7185: bool
google::protobuf::InsertIfNotPresent<std::map<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::pair<void const*,
int>, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > > >(std::map<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::pair<void const*,
int>, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > >*, std::map<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >, std::pair<void const*,
int>, std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > >::value_type::first_type const&,
std::map<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> >, std::pair<void const*, int>,
std::less<std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > >,
std::allocator<std::pair<std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const, std::pair<void
const*, int> > > >::value_type::second_type const&) (basic_string.h:196)
==3755== by 0x13EE8827:
google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::pair<void
const*, int> >::AddFile(google::protobuf::FileDescriptorProto const&,
std::pair<void const*, int>) (descriptor_database.cc:56)
... flurry of mismatched free/delete, etc.
==3755== by 0x123337: XPCOMGlueLoad(char const*) (nsXPCOMGlue.cpp:333)
==3755== by 0x12347B: mozilla::GetBootstrap(char const*)
(nsXPCOMGlue.cpp:408)
==3755== by 0x10D406: InitXPCOMGlue(char const*) (nsMailApp.cpp:247)
==3755== by 0x10D7C4: main (nsMailApp.cpp:295)
==3755==
{
<insert_a_suppression_name_here>
Memcheck:Free
fun:free
fun:_ZN6google8protobuf20OneofDescriptorProto10SharedDtorEv
fun:_ZN6google8protobuf20OneofDescriptorProtoD1Ev
fun:_ZN6google8protobuf20OneofDescriptorProtoD0Ev
fun:_ZN6google8protobuf8internal20RepeatedPtrFieldBase7DestroyINS0_16RepeatedPtrFieldINS0_20OneofDescriptorProtoEE11TypeHandlerEEEvv
fun:_ZN6google8protobuf16RepeatedPtrFieldINS0_20OneofDescriptorProtoEED1Ev
fun:_ZN6google8protobuf15DescriptorProtoD1Ev
fun:_ZN6google8protobuf15DescriptorProtoD0Ev
fun:_ZN6google8protobuf8internal20RepeatedPtrFieldBase7DestroyINS0_16RepeatedPtrFieldINS0_15DescriptorProtoEE11TypeHandlerEEEvv
fun:_ZN6google8protobuf16RepeatedPtrFieldINS0_15DescriptorProtoEED1Ev
fun:_ZN6google8protobuf15DescriptorProtoD1Ev
fun:_ZN6google8protobuf15DescriptorProtoD0Ev
fun:_ZN6google8protobuf8internal20RepeatedPtrFieldBase7DestroyINS0_16RepeatedPtrFieldINS0_15DescriptorProtoEE11TypeHandlerEEEvv
fun:_ZN6google8protobuf16RepeatedPtrFieldINS0_15DescriptorProtoEED1Ev
fun:_ZN6google8protobuf19FileDescriptorProtoD1Ev
fun:_ZN6google8protobuf25EncodedDescriptorDatabase3AddEPKvi
fun:_ZN6google8protobuf14DescriptorPool24InternalAddGeneratedFileEPKvi
fun:_ZN7mozilla8devtools8protobuf33protobuf_AddDesc_CoreDump_2eprotoEv
fun:_Z41__static_initialization_and_destruction_0ii
fun:_GLOBAL__sub_I_CoreDump.pb.cc
fun:call_init.part.0
fun:call_init
fun:_dl_init
fun:dl_open_worker
fun:_dl_catch_error
fun:_dl_open
fun:dlopen_doit
fun:_dl_catch_error
fun:_dlerror_run
fun:dlopen@@GLIBC_2.2.5
fun:_ZL12GetLibHandlePKc
fun:_ZL15ReadDependentCBPKc
fun:_ZL13XPCOMGlueLoadPKc
fun:_ZN7mozilla12GetBootstrapEPKc
fun:_ZL13InitXPCOMGluePKc
fun:main
}
Segmentation fault <===== one of the binaries invoked by the above
command fails here.
==3760==
==3760== HEAP SUMMARY:
==3760== in use at exit: 426,021 bytes in 1,928 blocks
==3760== total heap usage: 6,366 allocs, 4,438 frees, 12,676,013 bytes
allocated
==3760==
==3760== LEAK SUMMARY:
==3760== definitely lost: 0 bytes in 0 blocks
==3760== indirectly lost: 0 bytes in 0 blocks
==3760== possibly lost: 8,848 bytes in 150 blocks
==3760== still reachable: 416,533 bytes in 1,777 blocks
==3760== of which reachable via heuristic:
==3760== newarray : 1,536 bytes in 16 blocks
==3760== suppressed: 640 bytes in 1 blocks
==3760== Reachable blocks (those to which a pointer was found) are not
shown.
==3760== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3760==
==3760== For counts of detected and suppressed errors, rerun with: -v
==3760== ERROR SUMMARY: 155 errors from 37 contexts (suppressed: 1 from 1)
Traceback (most recent call last):
File "runtestlist.py", line 107, in <module>
line = proc.stdout.readline()
KeyboardInterrupt
xfwm4: Fatal IO error 11 (Resource temporarily unavailable) on X server
:2.0.
/NREF-COMM-CENTRAL/comm-central/mozilla/../mail/testsuite-targets.mk:30:
recipe for target 'mozmill' failed
make: *** [mozmill] Interrupt
[Note the Segmentation error]?
===
So I invoked valgrind under gdb directly.
ishikawa@ip030:/NREF-COMM-CENTRAL/comm-central$ gdb /usr/local/bin/valgrind
GNU gdb (GDB) 7.10.50.20160102-cvs
Copyright (C) 2016 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/valgrind...done.
(gdb) run
Starting program: /usr/local/bin/valgrind --verbose
--trace-children=yes --smc-check=all-non-file --gen-suppressions=all
--malloc-fill=0xA5 --free-fill=0xC3 --leak-check=full --num-callers=50
--suppressions=$HOME/Dropbox/myown.sup
--suppressions=$HOME/Dropbox/myown32.sup --show-possibly-lost=no
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin -jsbridge 24242
-foreground -profile
/NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile
process 3973 is executing new program:
/usr/local/lib/valgrind/memcheck-amd64-linux
==3973== Memcheck, a memory error detector
==3973== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==3973== Using Valgrind-3.13.0.SVN and LibVEX; rerun with -h for
copyright info
==3973== Command: /NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin
-jsbridge 24242 -foreground -profile
/NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile
==3973==
--3973-- Valgrind options:
--3973-- --verbose
--3973-- --trace-children=yes
--3973-- --smc-check=all-non-file
--3973-- --gen-suppressions=all
--3973-- --malloc-fill=0xA5
--3973-- --free-fill=0xC3
--3973-- --leak-check=full
--3973-- --num-callers=50
--3973-- --suppressions=/home/ishikawa/Dropbox/myown.sup
--3973-- --suppressions=/home/ishikawa/Dropbox/myown32.sup
--3973-- --show-possibly-lost=no
--3973-- Contents of /proc/version:
--3973-- Linux version 4.8.0-2-amd64 (debian-ker...@lists.debian.org)
(gcc version 5.4.1 20161202 (Debian 5.4.1-4) ) #1 SMP Debian 4.8.15-2
(2017-01-04)
--3973--
--3973-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
--3973-- Page sizes: currently 4096, max supported 4096
--3973-- Valgrind library directory: /usr/local/lib/valgrind
--3973-- Reading syms from
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin
--3973-- Reading syms from /lib/x86_64-linux-gnu/ld-2.24.so
--3973-- Considering
/usr/lib/debug/.build-id/09/5935d2da92389e2991f2b56d14dab9e6978696.debug ..
--3973-- .. build-id is valid
--3973-- Reading syms from /usr/local/lib/valgrind/memcheck-amd64-linux
--3973-- object doesn't have a dynamic symbol table
--3973-- Scheduler: using generic scheduler lock implementation.
--3973-- Reading suppressions file: /home/ishikawa/Dropbox/myown.sup
--3973-- Reading suppressions file: /home/ishikawa/Dropbox/myown32.sup
--3973-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
==3973== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-3973-by-ishikawa-on-???
==3973== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-3973-by-ishikawa-on-???
==3973== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-3973-by-ishikawa-on-???
==3973==
==3973== TO CONTROL THIS PROCESS USING vgdb (which you probably
==3973== don't want to do, unless you know exactly what you're doing,
==3973== or are doing some strange experiment):
==3973== /usr/local/lib/valgrind/../../bin/vgdb --pid=3973 ...command...
==3973==
==3973== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==3973== /path/to/gdb
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin
==3973== and then give GDB the following command
==3973== target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=3973
==3973== --pid is optional if only one valgrind process is running
==3973==
--3973-- REDIR: 0x401af50 (ld-linux-x86-64.so.2:strlen) redirected to
0x380a80e8 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--3973-- REDIR: 0x40198a0 (ld-linux-x86-64.so.2:index) redirected to
0x380a8102 (vgPlain_amd64_linux_REDIR_FOR_index)
--3973-- Reading syms from
/usr/local/lib/valgrind/vgpreload_core-amd64-linux.so
--3973-- Reading syms from
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-linux.so
==3973== WARNING: new redirection conflicts with existing -- ignoring it
--3973-- old: 0x0401af50 (strlen ) R-> (0000.0)
0x380a80e8 vgPlain_amd64_linux_REDIR_FOR_strlen
--3973-- new: 0x0401af50 (strlen ) R-> (2007.0)
0x04c2ec60 strlen
--3973-- REDIR: 0x4019ac0 (ld-linux-x86-64.so.2:strcmp) redirected to
0x4c2fd60 (strcmp)
--3973-- REDIR: 0x401ba60 (ld-linux-x86-64.so.2:mempcpy) redirected to
0x4c33130 (mempcpy)
--3973-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.24.so
--3973-- Considering
/usr/lib/debug/.build-id/75/b2a574fa9c03e43b58f53b424b1daec1211862.debug ..
--3973-- .. build-id is valid
--3973-- Reading syms from /lib/x86_64-linux-gnu/libdl-2.24.so
--3973-- Considering
/usr/lib/debug/.build-id/e4/8bb27b88670405041a12eefef9ef586f6e1533.debug ..
--3973-- .. build-id is valid
--3973-- Reading syms from /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
--3973-- object doesn't have a symbol table
--3973-- Reading syms from /lib/x86_64-linux-gnu/libm-2.24.so
--3973-- Considering
/usr/lib/debug/.build-id/d0/4c68ec51462ba3088cf1b19d54e1706463f723.debug ..
--3973-- .. build-id is valid
--3973-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
--3973-- Considering
/usr/lib/debug/.build-id/90/f96c5be1c683de41a42ab262411fb7a3876fb2.debug ..
--3973-- .. build-id is valid
--3973-- Reading syms from /lib/x86_64-linux-gnu/libc-2.24.so
--3973-- Considering
/usr/lib/debug/.build-id/4b/9cc30ba41f027a0dca6cd877f59f0db38f4025.debug ..
--3973-- .. build-id is valid
--3973-- REDIR: 0x5b7a510 (libc.so.6:strcasecmp) redirected to 0x4a26742
(_vgnU_ifunc_wrapper)
--3973-- REDIR: 0x5b75fc0 (libc.so.6:strcspn) redirected to 0x4a26742
(_vgnU_ifunc_wrapper)
--3973-- REDIR: 0x5b7c800 (libc.so.6:strncasecmp) redirected to
0x4a26742 (_vgnU_ifunc_wrapper)
--3973-- REDIR: 0x5b78430 (libc.so.6:strpbrk) redirected to 0x4a26742
(_vgnU_ifunc_wrapper)
--3973-- REDIR: 0x5b787c0 (libc.so.6:strspn) redirected to 0x4a26742
(_vgnU_ifunc_wrapper)
--3973-- REDIR: 0x5b79b90 (libc.so.6:memmove) redirected to 0x4a26742
(_vgnU_ifunc_wrapper)
--3973-- REDIR: 0x5b78140 (libc.so.6:rindex) redirected to 0x4c2e5f0
(rindex)
--3973-- REDIR: 0x5b70d30 (libc.so.6:malloc) redirected to 0x4c2bb1f
(malloc)
--3973-- REDIR: 0x5c1bbf0 (libc.so.6:__strcasecmp_avx) redirected to
0x4c2f4a0 (strcasecmp)
Program received signal SIGSEGV, Segmentation fault.
0x000000080470fdf8 in ?? ()
(gdb) where
#0 0x000000080470fdf8 in ?? ()
#1 0x0000000802e8df30 in ?? ()
#2 0x000000000010d76b in ?? ()
#3 0x0000000802008460 in ?? ()
#4 0x0000000802e8df30 in ?? ()
#5 0x0000000000001c00 in ?? ()
#6 0x0000000038c6bb00 in ?? ()
#7 0x0000000000000601 in ?? ()
#8 0x0000000000011af3 in ?? ()
#9 0x0000000000000000 in ?? ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 3973] will be killed.
Quit anyway? (y or n) y
ishikawa@ip030:/NREF-COMM-CENTRAL/comm-central$ /usr/local/bin/valgrind
--help
===
Oh by the way, I added --vex-iropt-register... in the option.
valgrind --vex-iropt-register-updates=allregs-at-mem-access --verbose
--trace-children=yes --smc-check=all-non-file --gen-suppressions=all
--malloc-fill=0xA5 --free-fill=0xC3 --leak-check=full --num-callers=50
--suppressions=$HOME/Dropbox/myown.sup
--suppressions=$HOME/Dropbox/myown32.sup --show-possibly-lost=no
/NREF-COMM-CENTRAL/objdir-tb3/dist/bin/thunderbird-bin -jsbridge 24242
-foreground -profile
/NREF-COMM-CENTRAL/objdir-tb3/_tests/mozmill/mozmillprofile
But something segfaults anyway.
[...]
--5688-- object doesn't have a symbol table
--5688-- REDIR: 0x5b76820 (libc.so.6:strncat) redirected to 0x4a26742
(_vgnU_ifunc_wrapper)
Segmentation fault
ishikawa@ip030:/NREF-COMM-CENTRAL/comm-central$ --5688-- REDIR:
0x5b72dd0 (libc.so.6:posix_memalign) redirected to 0x4c2de3a
(posix_memalign)
--5688-- Reading syms from
/usr/lib/x86_64-linux-gnu/libtxc_dxtn_s2tc.so.0.0.0
--5688-- object doesn't have a symbol table
--5688-- REDIR: 0x5c1bad0 (libc.so.6:__strspn_sse42) redirected to
0x4c33530 (strspn)
--5688-- REDIR: 0x5b79c90 (libc.so.6:__memcpy_chk_sse2_unaligned)
redirected to 0x4c33220 (__memcpy_chk)
[...]
===
The final part of sstrace output.
getpid() = 4280
gettid() = 4280
write(1029, "F", 1) = 1
rt_sigprocmask(SIG_SETMASK, [], ~[KILL STOP], 8) = 0
open("/tmp/thunderbird_ishikawa/.parentlock", O_WRONLY|O_CREAT|O_TRUNC,
0666) = 6
rt_sigprocmask(SIG_SETMASK, ~[KILL STOP], NULL, 8) = 0
gettid() = 4280
read(1028, "F", 1) = 1
fcntl(6, F_GETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=0,
l_len=0, l_pid=0}) = 0
fcntl(6, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=0}) = 0
lstat("/tmp/thunderbird_ishikawa/lock", 0xffeffe100) = -1 ENOENT (No
such file or directory)
uname({sysname="Linux", nodename="ip030", ...}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xffeffbab8} ---
+++ killed by SIGSEGV +++
It is possible that the signal handler was not completely installed
before a signal (SIGSEGV) was generated?
=====
The above is the situation under .8.0-2-amd6 kernel (Debian GNU/Linux )
---
To my consternation, this is kernel-dependent.
Under the vanilla kernel I created, valgrind runs just fine
Linux ip030 3.19.5 #1 SMP Mon Apr 20 08:50:21 JST 2015 x86_64 GNU/Linux
Any thoughts?
------------------------------------------------------------------------------
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
