You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update config parsing methods to ensure that any built-in functions that allocate memory for linked list data structures don't leak/orphan memory with subsequent calls
#47
Open
morgant opened this issue
Aug 24, 2024
· 0 comments
As discovered in Issue #45, SetStartFunction() in mlvwm/config.c contains a bug which can orphan linked list objects, leaking memory, with subsequent parsing of InitFunction/RestartFunction built-in function blocks in config files. This is because it references a pointer stored in the Scr variable's data structure, then allocates memory for a new object into that referenced variable in the first iteration of the parsing loop, effectively starting a new linked list instead of appending to the existing one, if one exists. Unfortunately, while it intentionally replaces the old linked list of parsed configuration data/settings upon subsequent executions, it doesn't actually free any prior linked list objects if they already exist.
Since this parsing into linked lists of data/settings is a common pattern in the mlvwm implementation, I suspect this bug occurs in a number of the other configuration parsing methods in mlvwm/config.c. Upon completing issue #45, let's look for and fix any similar memory leak bugs en masse.
The text was updated successfully, but these errors were encountered:
As discovered in Issue #45,
SetStartFunction()
inmlvwm/config.c
contains a bug which can orphan linked list objects, leaking memory, with subsequent parsing ofInitFunction
/RestartFunction
built-in function blocks in config files. This is because it references a pointer stored in theScr
variable's data structure, then allocates memory for a new object into that referenced variable in the first iteration of the parsing loop, effectively starting a new linked list instead of appending to the existing one, if one exists. Unfortunately, while it intentionally replaces the old linked list of parsed configuration data/settings upon subsequent executions, it doesn't actually free any prior linked list objects if they already exist.Since this parsing into linked lists of data/settings is a common pattern in the
mlvwm
implementation, I suspect this bug occurs in a number of the other configuration parsing methods inmlvwm/config.c
. Upon completing issue #45, let's look for and fix any similar memory leak bugs en masse.The text was updated successfully, but these errors were encountered: