libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] ptrace-unwind not working at head


From: Humberto Abdelnur
Subject: Re: [Libunwind-devel] ptrace-unwind not working at head
Date: Fri, 19 Feb 2010 11:28:02 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)


After digging into the libunwind code I found that the problem was in the
file src/os-linux.h at line 269

if (!cp)
 continue;
cp = scan_string (cp, NULL, 0);
if (!cp || dash != '-' || colon != ':')
 continue;  
since scan_string with buf_size 0 always returns 0. So for me it does not make sense, does it?
So, i removed and it works well afterwards.

The code is trying to parse a string of the format:

       /* scan: "LOW-HIGH PERM OFFSET MAJOR:MINOR INUM PATH" */

Is it possible that your version of Linux has a special /proc/pid/maps that the code doesn't understand?

$ cat /proc/13930/maps
00400000-004be000 r-xp 00000000 08:01 565300                             /bin/bash

I think that line of code is trying to skip over the path (/bin/bash) in this example and position cp to the first character after the path.

My version seems to be right as well

$ cat /proc/14415/maps
00400000-00616000 r-xp 00000000 08:04 234741                             /usr/bin/python2.6

but if you analyze the scan_string function, each time that buf_size is 0, then the return value will be NULL.
Then the second IF guard will be always true.
However, it is right that it needs to skip over the path, but then we need to change the guard from:

if (!cp || dash != '-' || colon != ':')

to

if (dash != '-' || colon != ':')

do you agreed?

Re: memory leak

I was able to reproduce your problem. But I thought it was caused by mapping the target elf image too many times, rather than the mmaps called by mempool_init().

src/ptrace/_UPT_find_proc_info.c:get_unwind_info() has a call to munmap, but it doesn't seem to be working well  (i.e. there is a leak somewhere).

The reason why libunwind has its own memory allocator is that it could be used to implement a heap profiler. So libunwind can't call malloc directly.

 -Arun

I found 3 leaks, the biggest is in the src/ptrace/_UPT_find_proc_info.c:get_unwind_info() function as you mentioned,
and there are two other minor leaks in the src/dwarf/global.c:dwarf_init(),  as I said before, these mempools are never unmapped.

Currently i did a workaround that works for my application (I just unmap the memory before returning get_unwind_info()). Any ideas of where that will be appropriated?

thanks again,

Humberto



reply via email to

[Prev in Thread] Current Thread [Next in Thread]