[BUG] Leaks on mlx_init (glfw) about mlx42

[W2Wizard]

Could you please share the entire valgrind log? I'm mainly interested in the summary.

[CafeurOff]

Could you please share the entire valgrind log? I'm mainly interested in the summary.

Hi, in attach file there is leaks files (too big to copy here 38k lines of summary just 2 seconds after i launch mlx )

leak.txt

[W2Wizard]

Checking the logs, there are no leaks:

The "still reachable" references memory that is still accessible but not lost. So for instance a static variable. That message is informative rather than indicative. There are still references to it from valid pointers in the program is what its referring to.

If the "definitely lost" would have any value it would be a clear cut indication that memory is being leaked.

TL;DR Not a leak.

[CafeurOff]

Sorry for the late reply

I re-run the test this evening with absolutely nothing changed and here is valgrind's summary:

==1725== Memcheck, a memory error detector
==1725== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1725== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==1725== Command: ./a.out
==1725==
==1725==
==1725== HEAP SUMMARY:
==1725==     in use at exit: 266,677 bytes in 2,631 blocks
==1725==   total heap usage: 63,987 allocs, 61,356 frees, 47,671,492 bytes allocated
==1725==
==1725== 64 bytes in 1 blocks are definitely lost in loss record 1,848 of 2,004
==1725==    at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
==1725==    by 0x6B26879: ???
==1725==    by 0x63EB7DF: ???
==1725==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==1725==    by 0x40100E8: call_init (dl-init.c:30)
==1725==    by 0x40100E8: _dl_init (dl-init.c:119)
==1725==    by 0x49F9AEC: _dl_catch_exception (dl-error-skeleton.c:182)
==1725==    by 0x4014363: dl_open_worker (dl-open.c:758)
==1725==    by 0x49F9A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==1725==    by 0x40138F9: _dl_open (dl-open.c:837)
==1725==    by 0x48BF257: dlopen_doit (dlopen.c:66)
==1725==    by 0x49F9A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==1725==    by 0x49F9B4E: _dl_catch_error (dl-error-skeleton.c:227)
==1725==
==1725== 5,355 bytes in 255 blocks are definitely lost in loss record 2,000 of 2,004
==1725==    at 0x483877F: malloc (vg_replace_malloc.c:307)
==1725==    by 0x494DB7A: strdup (strdup.c:42)
==1725==    by 0x600C4A6: ???
==1725==    by 0x600C254: ???
==1725==    by 0x5FAFF73: ???
==1725==    by 0x5ED3436: ???
==1725==    by 0x5ED3CE8: ???
==1725==    by 0x5F4F0F0: ???
==1725==    by 0x5F50417: ???
==1725==    by 0x486FD02: ??? (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==1725==    by 0x485F477: ??? (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==1725==    by 0x4864B6A: glfwCreateWindow (in /usr/lib/x86_64-linux-gnu/libglfw.so.3.3)
==1725==
==1725== LEAK SUMMARY:
==1725==    definitely lost: 5,419 bytes in 256 blocks
==1725==    indirectly lost: 0 bytes in 0 blocks
==1725==      possibly lost: 0 bytes in 0 blocks
==1725==    still reachable: 261,226 bytes in 2,374 blocks
==1725==         suppressed: 32 bytes in 1 blocks
==1725== Reachable blocks (those to which a pointer was found) are not shown.
==1725== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1725==
==1725== For lists of detected and suppressed errors, rerun with: -s
==1725== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

main.c :

int32_t	main(void)
{
	mlx_t* mlx;

	mlx = mlx_init(500, 500, "MLX42", 0);
	mlx_loop(mlx);
	mlx_terminate(mlx);
	return (0);
}

And still reachable:

From a different point of view, some 42 campuses behave as if still reachable were a leak, since some subjects say: "All memory allocated on the heap must be released when necessary".

A still-reachable is an allocated value that is always accessible on the heap, even after a program has been exited.
But do you think it's possible to be fixed knowing it could come from glfw?

[W2Wizard]

See now that is most definitely a leak. If you could test this with one of GLFW's example (to cancel out if it's me that's doing smth stupid or glfw is at fault) that would be great.

https://github.com/glfw/glfw/tree/master/examples

A still-reachable is an allocated value that is always accessible on the heap, even after a program has been exited.

Only regarding definitely leaked, the still reachable is like I said just a indicator not a concern in terms of memory leakage.

But do you think it's possible to be fixed knowing it could come from glfw?

Could be and it's likely regarding that first log in creating a window but the dl_open one seems like something else