New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sudden Segementation Fault #1455
Comments
Unfortunately this only shows the actual signal handling, not what caused it. Can you take a look at things running Looking at the crash report: Which commit from |
I got the same crash on Arch Linux. I can try running the debugger on the weekend. For now, attached obj dump:
|
Can you attach a debugger in Something seems to be off with that call. Can you test with an explicit Also, does this still reproduce with the HEAD commit from |
I'm on vacation now. Give me some time to get home and check it there.
Thanks
Am 22. April 2024 21:14:24 WESZ schrieb BenBE ***@***.***>:
…Can you attach a debugger in `ProcessTable.c` on line 71; the one
calling `Process_makeCommandStr(p, settings);`.
Something seems to be off with that call. Can you test with an explicit
`assert(p);` right before that call?
Also, does this still reproduce with the HEAD commit from `main`?
--
Reply to this email directly or view it on GitHub:
#1455 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
|
@ArnuldOnData Your version is different from the one that the OP is using. Are you sure these are the same crash? |
Right. It is not the operating system version that crashed.
Am 23. April 2024 12:13:10 WESZ schrieb BenBE ***@***.***>:
…
@ArnuldOnData Your version is different from the one that the OP is
using. Are you sure these are the same crash?
--
Reply to this email directly or view it on GitHub:
#1455 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
|
He might be using different OS. I posted in the same issue here because both crashes look quite similar. |
The segmentation fault occurred again. |
@seidler Thank you for this update. Looking through this crash looks a bit strange, as the crash is not a classical NULL dereference on some data (or a double free), but somehow the vtable for the object that should be freed has no |
It didn't crash for me on valgrind, but I got some suspicious messages. Git hash 314d693 I can't know for sure that it's related, but I feel that it is likely. |
On first glance this looks like some DF or UAF. And from the stack traces from |
Just in case it helps, I have re-triggered the issue with -O0 -ggdb3 and got a slightly more detailed stack trace: valgrind-out.txt |
In case reading the status file of a process fails do not bail out and treat the process as a short lived one, since the process has already been added to the global process table. Free'ing it will lead to use-after-free issues. Fixes: 22d25db ("Linux: detect container process by different PID namespace") Closes: htop-dev#1455
In case parsing an essential pid entry file like 'status' we treat the process as a short living one and ignore it. In the relevant goto label the process structure is free'd, thus it must not have been inserted into the global process table. Reorder parsing the status file after potentially inserting the process into the process table. Fixes: 22d25db ("Linux: detect container process by different PID namespace") Closes: htop-dev#1455
@ScoreUnder thanks, these stack traces were very helpful. |
In case parsing an essential pid entry file like 'status' we treat the process as a short living one and ignore it. In the relevant goto label the process structure is free'd, thus it must not have been inserted into the global process table. Reorder parsing the status file after potentially inserting the process into the process table. Fixes: 22d25db ("Linux: detect container process by different PID namespace") Closes: htop-dev#1455
@seidler @ArnuldOnData : Can you please check if the provided patch in #1481 by @cgzones resolves the issue for you? TIA. |
I have run it built from that branch for 4.5 hours and it doesn't seem to have hit any issues, so this is likely fixed on my end after those changes |
With the applied patch htop is running for hours without any problem. |
When parsing an essential pid entry file like 'status' fails, we treat the process as a short-lived one and skip adding it into the process table. This should be done before the process is added, as the goto label used for error handling can free the process structure, thus causing an use-after-free scenario. Fixes: 22d25db ("Linux: detect container process by different PID namespace") Closes: htop-dev#1455
After a few minutes runtime htop aborts with a segementation fault.
uname -a :
`linux asus 5.14.21-150500.55.52-default #1 SMP PREEMPT_DYNAMIC Tue Mar 5 16:53:41 UTC 2024 (a62851f) x86_64 x86_64 x86_64 GNU/Linux
lsb_release -a:
htop.objdump.gz
The text was updated successfully, but these errors were encountered: