Closed Jacobfaib closed 2 months ago
Yeah, this is bad. Apparently log_msg() malloc
's some inline buffer with the object, then we do a placement new on it for delayed messages (messages that we want to buffer until after we're done configuring). Later we delete
the object, which then delete
s the pointer without a size. These are potentially two different allocators that can lead to memory corruption. An easy way to work around this is to replace malloc
with ::operator new(sz)
, since we'll be calling ::operator delete(p)
later anyway -- at least then it'll be consistent.
Apparently log_msg() malloc's some inline buffer with the object, then we do a placement new on it for delayed messages (messages that we want to buffer until after we're done configuring).
Yeah lol I saw this too. I have no idea why a simple
char *message;
member in the allocated struct was insufficient...
Yeah, I don't either, but I'd rather not change it for fear of regressing some corner performance case or something. Using a consistent allocator should do the trick.
Should be resolved in latest master.