Andrey Zonov <[email protected]> writes: > On 8/27/12 1:30 PM, Petr Machata wrote: >> Andrey Zonov <[email protected]> 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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
