[Ltrace-devel] Segfault after a call to exec in ltrace 0.5.3

[Qais Yousef]

Hi,

I've been encountering a segfault that according to the printed debug
messages always happens after a call to exec(). I am not familiar with
the code but my attempt to understand the cause lead me to create the
attached patch which seems to fix the problem for me.

According to what I see, before a call to exec(),
breakpoint_being_enabled pointer was set which will be checked on the
next call to breakpoint_handler()to reenable it. If a call to exec()
after this variable is set and before it is cleared happens, all
breakpoints will be reinitialised and the symbol list is recreated. Now
on the next call to breakpoint_handler() after exec, the
breakpoint_being_enabled pointer structure has some invalid references
and could cause a segfault (or in other cases unaligned memory access).

We have our own port of ltrace to work on our Meta architecture. I
wonder if there could be something wrong with our port that somehow
causes the problem? I failed to make any connection. Or the patch I
attached makes sense?

I get the segfault when running:
	$ ltrace gst-inspect

Originally I used gst-launch, but gst-inspect gives similar results and
you won't have to create any pipeline.

Any comments would be appreciated.

Thanks,
Qais
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltrace-0.5.3-segfault-on-exec.patch
Type: application/octet-stream
Size: 274 bytes
Desc: ltrace-0.5.3-segfault-on-exec.patch
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20120220/82e1a054/attachment.obj>