From: Laris Benkis <laris@tpn.cc>
To: Adrien Kunysz <adrien@kunysz.be>
Cc: systemtap@sourceware.org
Subject: Re: probe process.function on libc not working
Date: Thu, 05 Jan 2012 02:00:00 -0000 [thread overview]
Message-ID: <4F0502AB.9000402@tpn.cc> (raw)
In-Reply-To: <20120104205832.GA771@chouffe>
[-- Attachment #1: Type: text/plain, Size: 2248 bytes --]
On 04/01/2012 3:58 PM, Adrien Kunysz wrote:
> On Wed, Jan 04, 2012 at 09:09:51AM -0500, Laris Benkis wrote:
>>>> Warning: child process exited with signal 11 (Segmentation fault)
>>> What does the backtrace, the EIP and the code around the EIP in that
>>> core look like?
>> I've attached the core file. Here are the registers and backtrace. Thanks
>> Laris
>>
>> (gdb) info registers
>> eax 0xfffff000 -4096
>> ecx 0x2400 9216
>> edx 0x800000 8388608
>> ebx 0x44fdeff4 1157492724
>> esp 0xbf84c85c 0xbf84c85c
>> ebp 0x44e16000 0x44e16000
>> esi 0x8 8
>> edi 0x1 1
>> eip 0xbf850070 0xbf850070
>> eflags 0x10206 [ PF IF RF ]
>> cs 0x73 115
>> ss 0x7b 123
>> ds 0x7b 123
>> es 0x7b 123
>> fs 0x0 0
>> gs 0x33 51
>> (gdb) bt
>> #0 0xbf850070 in ?? ()
>> #1 0x0000000b in ?? ()
>> #2 0x44e16a54 in ?? ()
>> #3 0x44e0ee78 in ?? () from /lib/ld-2.14.90.so
>> Backtrace stopped: Not enough registers or memory available to unwind
>> further
> That core file is pretty much useless without de debug symbols and
> I don't have a Fedora machine. What do you see if you disassemble
> the code around the instruction pointer? (0xbf850070).
>
> Another idea to try to understand this would be to see whether probing
> only part of the libc functions cause the problem. Is this just with
> one execve()-related function? All the functions? Or does this happen
> only when probing many functions? If you are familiar with Python
> an adaptation of the script Timo posted last month might be helpful
> to explore this: http://sourceware.org/ml/systemtap/2011-q4/msg00402.html
This is pushing my gdb knowledge. Here is what I get for the
disassemble command:
(gdb) disassemble 0xbf850070
No function contains specified address.
I guess thats probably not what you intended. Can you give me some more
specific directions.
I've attached the ld-2.14.90.so, ls and libc debug symbols. I hope that
helps.
I'm not familiar with python but I'll have a look at it to see it I can
make it work.
Thanks
Laris
[-- Attachment #2: ld-2.14.90.so.debug.gz --]
[-- Type: application/gzip, Size: 254949 bytes --]
[-- Attachment #3: libc-2.14.90.so.debug.gz --]
[-- Type: application/gzip, Size: 2511799 bytes --]
[-- Attachment #4: ls.debug.gz --]
[-- Type: application/gzip, Size: 122746 bytes --]
prev parent reply other threads:[~2012-01-05 2:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-23 5:00 Laris Benkis
2012-01-04 5:23 ` Laris Benkis
2012-01-04 8:54 ` Adrien Kunysz
2012-01-04 14:15 ` Laris Benkis
2012-01-04 20:55 ` Adrien Kunysz
2012-01-05 2:00 ` Laris Benkis [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F0502AB.9000402@tpn.cc \
--to=laris@tpn.cc \
--cc=adrien@kunysz.be \
--cc=systemtap@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).