[DTrace-devel] [PATCH 2/6] dtprobed: stop malloc making syscalls in the DOF parser child

[Nick Alcock]

On 25 May 2023, Eugene Loh stated:

> On 5/25/23 17:12, Nick Alcock wrote:
>
>> On 22 May 2023, Eugene Loh via DTrace-devel stated:
>>
>>> Shouldn't this have at least one test?
>> It does -- tst.manyprobes.sh emits 200+KiB of DOF, which is more than
>> enough to trigger this bug without this fix.
>
> But that test doesn't show up until the next patch?

Yeah, because otherwise tst.manyprobes.sh would fail because this patch
wasn't there. I wanted the >64KiB-of-DOF thing to visibly fix something
on addition, and without this going first it wouldn't.

>> I don't quite understand how it knows that malloc() and free() are
>> paired like that, I mean if anything has side effects (on the heap) it's
>> malloc(). I think it must be the __attribute__((malloc)) it's declared
>> with: it knows that an __attribute__((malloc))'ed pointer is guaranteed
>> to be new, and that free() consumes it, and that therefore the two put
>> together with nothing between them are NOP... which is usually true, but
>> here we are interested in its usually-invisible side effects on the heap.
>> It even realises that writing into it, then reading out of it are NOP,
>> probably because it eliminates the read (since nothing uses its result),
>> then the write, then oh look we can drop the whole pointer.
>>
>> Modern compilers are pretty smart.
>
> Maybe making the allocated pointer volatile or something?  I don't know.

Tried that, no effect :( I have a -fno-lto in Build too to stop any
future LTOing we might do from getting its claws on this code too.

-- 
NULL && (void)