[Ltrace-devel] Some patches for ltrace
Petr Machata
pmachata at redhat.com
Mon Aug 27 13:35:44 UTC 2012
Andrey Zonov <zont at FreeBSD.org> writes:
> On 8/27/12 1:30 PM, Petr Machata wrote:
>> Andrey Zonov <zont at FreeBSD.org> writes:
>>
>>> I'm now porting ltrace on FreeBSD
One more nit. I don't like that the directory is called FreeBSD. Why
not call it "freebsd"? That's what the triplet name is.
>>
>> Thank you. Next time around, would you please be so kind as to post
>> each of those as a patch, like what git-format-patch does? This would
>> allow me to review in e-mail, and eventually apply them.
>
> Sure, but I thought that the merge from my tree is easier way to apply
> them.
I'd need to add a remote and then cherry-pick, which is annoying.
Sending patches to mailing list is important for review anyway.
>> You commit messages start with dashes. Our don't. The first line of a
>> commit message acts similarly to Subject: in e-mail messages.
>
> AFAIK, you can change commit message as you want.
I guess I could if you posted them as patches ;) I could anyway, but
then I'd need to amend stuff after each cherry pick, which is yet more
work for me. In any case, I hope you will want to merge your FreeBSD
work to official ltrace repository eventually, and it is desirable that
it fits the style of the rest of the repo.
>> Apart from the particular commits that you point out. Most of the
>> FreeBSD code is very similar to Linux code. This is guaranteed to
>> bitrot. Either FreeBSD will see fixes that would be useful for Linux,
>> or the other way around. It seems like the job control parts should be
>> fairly similar among these two OS's, and it should be possible to reuse
>> this and only call back to OS hooks for the low-level work.
>
> The thread implementation is strongly different in FreeBSD, that is the
> main problem of the port.
Yeah, I see that proc.c has changed a fair deal. If more changes are
comming to trace.c, than sharing might indeed be impractical. Is that
the case?
>> Also note that I intended to merge pmachata/abi branch for some time
>> now. I don't think it collides with your work, but it does touch a lot
>> of ltrace core, and might introduce bugs that you will see on FreeBSD as
>> well. I'll try to get around to the merge really soon now.
>>
>
> Where can I find this branch to try it?
Apologies, it's actually called pmachata/revamp. It used to be called
pmachata/abi before it turned out that deeper changes are necessary for
the intended functionality. I'll need to rebase it on top of current
master, which has seen a few changes in the mean time, and then merge
it. Hopefully I'll get around it sometime this week.
>>> a2d199eda1f0e6dd5e3dc38fdef9383dca602993
>>
>> I don't understand the problem. When does it break and how? Leaking
>> memory is certainly less bad than crashing, but we would prefer fixing
>> the underlying bug.
>
> This is a using memory after free(3). I found it, because "FreeBSD
> current" uses memory allocator that trashes memory after free(3) and
> ltrace got SIGSEGV.
>
> You can easily reproduce that problem with valgrind under Linux. Test
> program is attached.
>
> $ valgrind ./ltrace -f ./run 1 /bin/sleep 1
OK. I'll look into this and see if I can come up with a reasonable
solution.
>>> ebd3e4c7e68065f1829ca84d7830c583efc12cff
>>
>> Why is this needed?
>
> Also using after free(3).
Interesting. I'm talking about "Save callstack on exec", are you as
well?
Thanks,
PM
More information about the Ltrace-devel
mailing list