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
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
