[BUG] Address sanitizer reports leaks
Closed this issue · 2 comments
- Linux machine (Archlinux)
- MLX42
v2.3.1
I have copied the same code in theREADME.md, I compiled it with-fsanitize=leakflag and it reports memory leaks
when I removed themlx_terminate()function it's no longer showing memory leaks
This stack trace is pretty much useless, the absolute minimum I have been able to boil it down to is:
w2wizard@WizDesktop:/mnt/c/Users/leond/Desktop/Files/MLX42$ clang main.c -ldl -Iinclude ./build/libmlx42.a ./build/libglfw3.a -lX11 -ldl -pthread -lm -fsanitize=leak -fno-omit-frame-pointer -fno-optimize-sibling-calls -g
w2wizard@WizDesktop:/mnt/c/Users/leond/Desktop/Files/MLX42$ ./a.out
=================================================================
==1944==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 5355 byte(s) in 255 object(s) allocated from:
#0 0x420018 in malloc (/mnt/c/Users/leond/Desktop/Files/MLX42/a.out+0x420018)
#1 0x7f7154950f3a in strdup (/lib/x86_64-linux-gnu/libc.so.6+0x8af3a)
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x420aa8 in operator new(unsigned long) (/mnt/c/Users/leond/Desktop/Files/MLX42/a.out+0x420aa8)
#1 0x7f7151c42879 (<unknown module>)
SUMMARY: LeakSanitizer: 5419 byte(s) leaked in 256 allocation(s).Which makes even less sense because idk where this is coming from, nor where the new operator is being called.
To be exactly precise it's coming out of glfwTerminate in mlx_exit.c. But I have no leaks on MacOS when trying to run this.
Now this could be related to:
With Valgrind I get a bit more information, but still very bad.
==15900== 64 bytes in 1 blocks are definitely lost in loss record 1,991 of 2,292
==15900== at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434)
==15900== by 0x6DA4879: ???
==15900== by 0x66697DF: ???
==15900== by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==15900== by 0x40100E8: call_init (dl-init.c:30)
==15900== by 0x40100E8: _dl_init (dl-init.c:119)
==15900== by 0x4C39AEC: _dl_catch_exception (dl-error-skeleton.c:182)
==15900== by 0x4014363: dl_open_worker (dl-open.c:758)
==15900== by 0x4C39A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==15900== by 0x40138F9: _dl_open (dl-open.c:837)
==15900== by 0x4855257: dlopen_doit (dlopen.c:66)
==15900== by 0x4C39A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==15900== by 0x4C39B4E: _dl_catch_error (dl-error-skeleton.c:227)
==15900==
==15900== 112 (56 direct, 56 indirect) bytes in 1 blocks are definitely lost in loss record 2,248 of 2,292
==15900== at 0x483E1E8: calloc (vg_replace_malloc.c:1340)
==15900== by 0x704E24A: ???
==15900== by 0x6C4CF3B: ???
==15900== by 0x6C39480: ???
==15900== by 0x6C3964C: ???
==15900== by 0x6BF7250: ???
==15900== by 0x6BF9D14: ???
==15900== by 0x6BF4CF8: ???
==15900== by 0x6BB4AD7: ???
==15900== by 0x6BDDC15: ???
==15900== by 0x6BDB366: ???
==15900== by 0x6B88F51: ???
==15900==
==15900== 5,355 bytes in 255 blocks are definitely lost in loss record 2,284 of 2,292
==15900== at 0x483979B: malloc (vg_replace_malloc.c:393)
==15900== by 0x4B8DF3A: strdup (strdup.c:42)
==15900== by 0x5E8A4A6: ???
==15900== by 0x5E8A254: ???
==15900== by 0x5E2DF73: ???
==15900== by 0x5D51436: ???
==15900== by 0x5D51CE8: ???
==15900== by 0x5DCD0F0: ???
==15900== by 0x5DCE417: ???
==15900== by 0x424213: makeContextCurrentGLX (glx_context.c:163)
==15900== by 0x40EE80: glfwMakeContextCurrent (context.c:632)
==15900== by 0x40E710: _glfwRefreshContextAttribs (context.c:358)
Unless a clear stack trace can be established, there's nothing I can do about these specific leaks that seem to be outside of my control. Further more they originate from GLFW but if you actually look where these traces lead you it seems to be even out of their control.
I suggest your forward these to the GLFW Repo and ask them for advice.