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

[Eugene Loh]

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?
>> On 5/22/23 16:20, Nick Alcock via DTrace-devel wrote:
>>> and free() for the big allocation in another translation unit (and turn
>>> LTO off for that translation unit), or GCC will recognise that the
>>> malloc/free are do-nothing, and optimize them away.)
>> Isn't there a simpler solution?  I don't know.  Maybe assert(p = malloc()); free(p)?
> I tried that :( GCC doesn't stop optimizing just cos you're in an
> assertion, alas.
>
> 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.