[Bug runtime/12141] New: Segmentation fault in apps probed by libstdc++ i686

["jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12141

           Summary: Segmentation fault in apps probed by libstdc++ i686
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: runtime
        AssignedTo: systemtap@sources.redhat.com
        ReportedBy: jistone@redhat.com


I can reproduce this on Fedora 12 and 13, i686 only:

$ stap -e 'probe process("/usr/lib/libstdc++.so.6").function("operator new")
{next}' -c 'stap -V'

... produces no output, when the -c stap should print its version.  So instead
I left that probe running on its own, and ran the "stap -V" in gdb:

(gdb) run -V
Starting program: /usr/local/bin/stap -V
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x0020914c in _Settings ()
    at
/usr/src/debug/gcc-4.4.4-20100630/obj-i686-redhat-linux/i686-redhat-linux/libstdc++-v3/include/parallel/settings.h:276
276        _Settings() : algorithm_strategy(heuristic), [...]
(gdb) bt
#0  0x0020914c in _Settings ()
    at
/usr/src/debug/gcc-4.4.4-20100630/obj-i686-redhat-linux/i686-redhat-linux/libstdc++-v3/include/parallel/settings.h:276
#1  __static_initialization_and_destruction_0 ()
    at ../../../../libstdc++-v3/src/parallel_settings.cc:29
#2  global constructors keyed to parallel_settings.cc(void) ()
    at ../../../../libstdc++-v3/src/parallel_settings.cc:42
#3  0x0021208d in __do_global_ctors_aux () from /usr/lib/libstdc++.so.6
#4  0x0019cd34 in _init () from /usr/lib/libstdc++.so.6
#5  0x00771da0 in _dl_init_internal () from /lib/ld-linux.so.2
#6  0x0076388f in _dl_start_user () from /lib/ld-linux.so.2

NB: We haven't even reached main!

(gdb) disassemble /r 
Dump of assembler code for function _GLOBAL__I_parallel_settings.cc(void):
[...]
   0x00209142 <+674>:     c7 81 dc 29 00 00 00 00 00 00    movl  
$0x0,0x29dc(%ecx)
=> 0x0020914c <+684>:     c7 81 e0 29 cc 00 10 27 00 00    movl  
$0x2710,0xcc29e0(%ecx)
   0x00209156 <+694>:     c7 81 e4 29 00 00 00 00 00 00    movl  
$0x0,0x29e4(%ecx)

The 0xCC sticks out like a sore thumb...  And indeed, if I kill the running
probe, this 0xCC turns back into 0x00, so it's definitely our uprobes INT3, in
a very bad place.

$ stap -l 'process("/usr/lib/libstdc++.so.6").function("operator new")' -vv |&
grep pc=
probe operator new@../../../../libstdc++-v3/libsupc++/new_opnt.cc:37
process=/usr/lib/libstdc++.so.6.0.13 reloc=.dynamic pc=0xaf200
probe operator new@../../../../libstdc++-v3/libsupc++/new_op.cc:45
process=/usr/lib/libstdc++.so.6.0.13 reloc=.dynamic pc=0xaf150

$ nm /usr/lib/debug/usr/lib/libstdc++.so.6.0.13.debug | c++filt | grep
'operator new('
000af150 T operator new(unsigned int)
000af200 T operator new(unsigned int, std::nothrow_t const&)

So far, so good.  With -DDEBUG_UPROBES, I see:

stap_uprobe_change_plus:67: +uprobe spec 0 idx 0 process stap[2907] addr
00209200 pp process("/usr/lib/libstdc++.so.6.0.13").function("operator
new@../../../../libstdc++-v3/libsupc++/new_opnt.cc:37")
stap_uprobe_change_plus:67: +uprobe spec 1 idx 1 process stap[2907] addr
00209150 pp process("/usr/lib/libstdc++.so.6.0.13").function("operator
new@../../../../libstdc++-v3/libsupc++/new_op.cc:45")
stap_uprobe_change_minus:225: -uprobe spec 0 idx 0 process stap[2907] reloc
00209200 pp process("/usr/lib/libstdc++.so.6.0.13").function("operator
new@../../../../libstdc++-v3/libsupc++/new_opnt.cc:37")
stap_uprobe_change_minus:225: -uprobe spec 1 idx 1 process stap[2907] reloc
00209150 pp process("/usr/lib/libstdc++.so.6.0.13").function("operator
new@../../../../libstdc++-v3/libsupc++/new_op.cc:45")

The addrs here confirm what I saw in gdb's disassembly, but they're clearly not
the right place.  So where would gdb probe?

(gdb) b 'operator new(unsigned int)'
Breakpoint 2 at 0x20b8ca: file ../../../../libstdc++-v3/libsupc++/new_op.cc,
line 46.
(gdb) b 'operator new(unsigned int, std::nothrow_t const&)' 
Breakpoint 3 at 0x20b97a: file ../../../../libstdc++-v3/libsupc++/new_opnt.cc,
line 38.

So it looks like our probe addresses are missing some offset, as they're both
0x277a off from where they should be.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.