Skip to content

Fix some issues found by valgrind

Tim Wiederhake requested to merge twied/twm:valgrind into master

The found memory leaks are "static" leaks, i.e. one-time allocations that are free'd on program termination anyway. They do create a lot of noise in the output of analysis tools like valgrind though and make it harder to see if there are any actual, problematic memory leaks.

There are two leaks left:

32 bytes in 1 blocks are definitely lost in loss record 54 of 202
   at 0x4840808: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x4A7B885: ??? (in /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0)
   by 0x4A7BFBF: XRRQueryExtension (in /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0)
   by 0x12EC37: main (twm.c:334)

This appears to be a leak in libXrandr that twm can not do anything about.

168 bytes in 16 blocks are definitely lost in loss record 162 of 202
   at 0x4840808: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
   by 0x4B23D19: strdup (strdup.c:42)
   by 0x110801: yyparse (gram.y:648)
   by 0x128402: doparse (parse.c:115)
   by 0x128A44: ParseStringList (parse.c:233)
   by 0x1289FF: ParseTwmrc (parse.c:224)
   by 0x12F70A: main (twm.c:538)

The origin of this leak is the call to strdup in yyparse for STRING tokens and requires some rework of the parser to fix.

Merge request reports