segfault when compiled with leak-detective enabled and systemd >=254 about strongswan

[tobiasbrunner]

First, note that our leak detective is a development tool that shouldn't be enabled in production.

possibly related to ... since leak detective intercepts realloc, which may interfere with greedy_realloc.

I don't think so. This is probably because we don't override malloc_usable_size(), which means that if the leak detective is enabled, the pointer passed to that function will not be the one originally returned by the real malloc() function. That allocated memory area starts with some bookkeeping data and the pointer returned by leak detective's malloc() is somewhere in this area but not at the beginning from where glibc probably tries to determine its own metadata.

I've pushed a possible fix to the 2045-ld-malloc-size branch.

[alexfanqi]

tested on my machine and it fixes the segfault.

First, note that our leak detective is a development tool that shouldn't be enabled in production.

Thanks for the note. I reported it because this one is the cleanest example that reproduces the segfault I also had with other softwares on new systemd. So this example would imply after the systemd change, any software that overrides malloc may potentially also need to override malloc_usable_size.

[tobiasbrunner]

Thanks for testing. I've pushed the fix to master.

So this example would imply after the systemd change, any software that overrides malloc may potentially also need to override malloc_usable_size.

Yes, I'd assume so.