Memory leak in __execute_function #425
Labels
type:bug
Something's broken!
Comments
Quipyowert2
added a commit
to Quipyowert2/fvwm3
that referenced
this issue
Feb 4, 2021
When FUNC_DONT_EXPAND_COMMAND isn't set, expand_vars allocates a string and returns it. This string wasn't being freed by the calling function. Fixes fvwmorg#425.
Merged
ThomasAdam
pushed a commit
that referenced
this issue
Feb 4, 2021
When FUNC_DONT_EXPAND_COMMAND isn't set, expand_vars allocates a string and returns it. This string wasn't being freed by the calling function. Fixes #425.
|
Hi @Quipyowert2 I had a report from a user on IRC who had the latest I don't have a lot of time to check the reasons why. The stacktrace is here: http://www.linkerror.com/stuff/gdb.txt Thanks! |
Quipyowert2
added a commit
to Quipyowert2/fvwm3
that referenced
this issue
Feb 8, 2021
When a command starting with an asterisk was encountered, ModuleConfig was called, which calls AddToModList which frees its argument. Thus expaction shouldn't be freed if the command starts with an asterisk, as it was already freed in AddToModList. Fixes fvwmorg#425.
Merged
Quipyowert2
added a commit
to Quipyowert2/fvwm3
that referenced
this issue
Feb 8, 2021
When a command starting with an asterisk was encountered, ModuleConfig was called, which calls AddToModList which frees its argument sometimes. Then __execute_function tries to free the same pointer again. This commit fixes this by only freeing rline in AddToModList if it points at xasprintf'd memory, as freeing the memory from xasprintf won't invalidate expaction. Fixes fvwmorg#425.
Quipyowert2
added a commit
to Quipyowert2/fvwm3
that referenced
this issue
Feb 8, 2021
When a command starting with an asterisk was encountered, ModuleConfig was called, which calls AddToModList which frees its argument sometimes. Then __execute_function tries to free the same pointer again. This commit fixes this by only freeing rline in AddToModList if it points at xasprintf'd memory, as freeing the memory from xasprintf won't invalidate expaction. Fixes fvwmorg#425.
Quipyowert2
added a commit
to Quipyowert2/fvwm3
that referenced
this issue
Feb 8, 2021
When a command starting with an asterisk was encountered, ModuleConfig was called, which calls AddToModList which frees its argument sometimes. Then __execute_function tries to free the same pointer again. This commit fixes this by only freeing rline in AddToModList if it points at xasprintf'd memory, as freeing the memory from xasprintf won't invalidate expaction. Fixes fvwmorg#425.
Quipyowert2
added a commit
to Quipyowert2/fvwm3
that referenced
this issue
Feb 8, 2021
When a command starting with an asterisk was encountered, ModuleConfig was called, which calls AddToModList which frees its argument sometimes. Then __execute_function tries to free the same pointer again. This commit fixes this by only freeing rline in AddToModList if it points at xasprintf'd memory, as freeing the memory from xasprintf won't invalidate expaction. Fixes fvwmorg#425.
ThomasAdam
pushed a commit
that referenced
this issue
Feb 8, 2021
When a command starting with an asterisk was encountered, ModuleConfig was called, which calls AddToModList which frees its argument sometimes. Then __execute_function tries to free the same pointer again. This commit fixes this by only freeing rline in AddToModList if it points at xasprintf'd memory, as freeing the memory from xasprintf won't invalidate expaction. Fixes #425.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks for reporting your bug here! The following template will help with
giving as much information as possible so that it's easier to diagnose and
fix.
Upfront Information
Please provide the following information by running the command and providing
the output.
fvwm3 --version)ccb7eb4 although
fvwm3 --versionsaysfvwm3 1.0.3 (1.0.2-48-g356e327f)openSUSE 15.2 WSL
uname -sp)Linux x86_64
Expected Behaviour
Ideally, no memory leaks.
What were you trying to do? Please explain the problem.
Check fvwm3 for memory leaks and other issues with Valgrind.
Actual Behaviour
valgrind --fullpath-after=$PWD/ --num-callers=100 --leak-check=full fvwm/fvwm3Relevant parts of Valgrind output:
What should have happened, but didn't?
Enabling logging
fvwm3has a means of logging what it's doing. Enabling this whenreproducing the issue might help. To do this, either change the means fvwm3
is started by adding
-vas in:or, once
fvwm3has loaded, sendSIGUSR2as in:The resulting logfile can be found in
$HOME/.fvwm/fvwm3-output.logSteps to Reproduce
How can the problem be reproduced?
valgrind --fullpath-after=$PWD/ --num-callers=100 --leak-check=full fvwm/fvwm3For this, the following is helpful:
fvwmconfiguration example (wherepossible). Start with a blank config file (
fvwm3 -f/dev/null) and go fromthere.
config.txt
The memory leak happens with default config and still happens with
fvwm3 -f /dev/nullYes, but with libgobject memory leaks instead of expand_vars.
Include your configuration with this issue.
Does Fvwm3 crash?
If fvwm3 crashes then check your system for a corefile. This is platform
dependant, however, check if:
ulimit -c)$HOMEor/tmp/.systemd), checkcoredumpctl list.coredumpctlmay need installing separately.If you find a corefile, install
gdband run:If you're using
coredumpctlthen use:Then from within the
(gdb)prompt, issue:... and include the output here.
Extra Information
There are also possible fontconfig memory leaks but these aren't the focus of the linked pull request.
Feel free to take a screen capture or video and upload to this issue if you
feel it would help.
Attach
$HOME/.fvwm/fvwm3-output.logfrom the step above.fvwm3-output.log
The text was updated successfully, but these errors were encountered: