[Ltrace-devel] Some patches for ltrace

[Petr Machata]

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