SUMMARY It does not happen on all the programs but on some I get the following error message: ERROR: failed to lock heaptrack output file /tmp/heaptrack_fifo29844: Resource temporarily unavailable (11) Any ideas why this happens?
odd, that's EAGAIN which isn't documented as a possible return value in https://linux.die.net/man/2/flock but as the error indicates, we should probably just try again? I'll try to write a patch eventually, but can't promise an ETA since I'm quite busy - so if you can reproduce it, try to wrap the flock in a loop that checks for EAGAIN?
This makes heaptrack unusable with affected programs.
Git commit 42a13a83ea3c16337685a020daaabcd3b44066c1 by Milian Wolff. Committed on 16/08/2021 at 09:06. Pushed by mwolff into branch 'master'. Rerun flock if it returns EAGAIN This error code return value is not documented, yet it seems to sometimes happen in the wild. Gracefully handle this situation by looping, hoping that it will succeed eventually. M +13 -2 src/track/libheaptrack.cpp https://invent.kde.org/sdk/heaptrack/commit/42a13a83ea3c16337685a020daaabcd3b44066c1
Can you try with this patch again? I hope that it will succeed eventually. But maybe it just loops indefinitely now?
(In reply to Milian Wolff from comment #1) > odd, that's EAGAIN which isn't documented as a possible return value in > https://linux.die.net/man/2/flock > > but as the error indicates, we should probably just try again? I'll try to > write a patch eventually, but can't promise an ETA since I'm quite busy - so > if you can reproduce it, try to wrap the flock in a loop that checks for > EAGAIN? Code should check for EWOULDBLOCK which is in the flock manual page list of returns: On many systems there are similar defines to this one: /usr/include/asm-generic/errno.h:#define EWOULDBLOCK EAGAIN /* Operation would block */ The question of course becomes who has the file locked such that LOCK_NB is causing the EWOULDBLOCK ?
(In reply to Chris E from comment #5) > (In reply to Milian Wolff from comment #1) > > odd, that's EAGAIN which isn't documented as a possible return value in > > https://linux.die.net/man/2/flock > > > > but as the error indicates, we should probably just try again? I'll try to > > write a patch eventually, but can't promise an ETA since I'm quite busy - so > > if you can reproduce it, try to wrap the flock in a loop that checks for > > EAGAIN? > > Code should check for EWOULDBLOCK which is in the flock manual page list of > returns: > On many systems there are similar defines to this one: > /usr/include/asm-generic/errno.h:#define EWOULDBLOCK EAGAIN /* > Operation would block */ > The question of course becomes who has the file locked such that LOCK_NB is > causing the EWOULDBLOCK ? whoops should have read PR first. smells like a bug in flock to me
I am using heaptrack version 1.3 and getting the same error on every run.
if it fails then debug it and give us more information. try with the latest master build from source and add more information as needed. or at the least figure out a reliable way to reproduce this for someone else. this works fine for many people so it seems to be something specific to your machine and without more info I cannot do anything about it. is there maybe something special about the disk/filesystem where the lock file is being put?
The error was caused by the parameters that were passed. Initially I gave my bash file as parameter for heaptrack, when I updated it and ran just the application, it worked fine.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!