Replies: 15 comments 17 replies
-
|
@joske Could be that the mutex which was removed in a change in main is getting weird because some old object file that hasn't been recompiled. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
yes, clean build with main merge in.
…On Sat, 16 Oct 2021 at 22:09, aristocratos ***@***.***> wrote:
@joske <https://github.com/joske>
Have you make clean since commit Merge changes from main
<88a2528>
?
Could be that the mutex which was removed in a change in main is getting
weird because some old object file that hasn't been recompiled.
Think I recognize the error message from problems like that earlier.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEB7R7R4BNLCMTS76OJ2PDUHHLWVANCNFSM5GD7GSGQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@joske |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
no not every time, typical of not thread safe code ;-)
…On Sat, 16 Oct 2021 at 22:13, aristocratos ***@***.***> wrote:
@joske <https://github.com/joske>
Yeah, I'm seeing it too now, but not every time, huh :\
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEB7R62IZS5VYMNQOIEQ7DUHHMH7ANCNFSM5GD7GSGQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
It also seem to be unstable in general when compiled with And can't debug it with |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Huh, seems gdb is not supported on M1... |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Use lldb. It works almost identical.
…On Sat, 16 Oct 2021, 22:40 aristocratos, ***@***.***> wrote:
Huh, seems gdb is not supported on M1...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#91 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEB7R4CMNANAPOVMMEHJHLUHHPL7ANCNFSM5GD7GSGQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@joske |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
still happening at random, even when not doing anything... |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
reproduction scenario: start btop with 100 ms refresh. Press 1 to hide CPU, wait a bit, in less than 1 minute: crash. Was already able to repro like this 3 times in a row. Edit: crash immediately after giving focus to another window... Edit 2: does not happen every time, but after disabling CPU view, crash is imminent. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Can't reproduce on my end, running stable so far. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Can you get an bigger trace? |
Beta Was this translation helpful? Give feedback.
-
|
On linux, also can not reproduce, macOS every time (debug build, not sure if that is related). SIGABRT also comes without debugging with lldb. Probably in another thread. This backtrace is only from main thread :-/. Will try to get backtrace from other thread. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Well yeah, I get a segmentation fault after about 2 seconds when compiling with |
Beta Was this translation helpful? Give feedback.
-
|
rebooted back in macOS, with same binary (did not recompile) I know see totally different behaviour: stalling of the GUI/app for several seconds and then continues, but no crash so far :-/. WTF |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
backtrace all threads: |
Beta Was this translation helpful? Give feedback.
11 replies
-
|
Can just comment out 1186-1193 and 1236-1255 for now. Will take another look at it later and try to salvage it. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, is probably a good idea to take a look at @giampaolo code in psutil and see how he solved it. |
Beta Was this translation helpful? Give feedback.
-
|
fixed it by only fetching arg_max once in Shared::init(). No point in re-fetching it every iteration of collect() - it should always return the same value. |
Beta Was this translation helpful? Give feedback.
-
|
Yup, seems to run fine with |
Beta Was this translation helpful? Give feedback.
-
|
changed it to use sysconf to get the arg_max. I guess if it starts up now, it's going to be fine ;-). |
Beta Was this translation helpful? Give feedback.
-
|
attaching to a running btop, and getting backtrace now gives: 1 - main, 2 - runner, 3, 4 - macos work queue threads, 5 - lldb? |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
Seems a little more sane. Probably need to look into how it could even get 14 threads running, any other instance of the "Runner" thread should be blocked by a pthread_mutex nevermind the fact that they would be using the same pthread_id which probably should have crashed the program at the third thread created :\ The leaking seems to have decreased a lot now. Need to do some longer tests to see if and how much it's still leaking. |
Beta Was this translation helpful? Give feedback.
-
|
maybe because of some corruption due to the ridiculous memory allocations? Yes, noticed the leaks are less too. Still leaks though. A reliable way to have it leak is to make a full build with btop running (make clean; make). I have htop & btop running, with htop filtered only on btop process. You see it shoot up during every build (and stays there). |
Beta Was this translation helpful? Give feedback.
-
|
if you hide process view, this doesn't happen, so something to do with processes being added/removed clearly. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
@aristocratos
with btop running (on intel hackintosh), I saw spotify was using cpu (probably the CPU reporting is still wrong on macOS), so I decided to quit it. I did so using the dock menu item, the result was a crash in btop:
Can not capture text, as the terminal is borked after a crash...
Beta Was this translation helpful? Give feedback.
All reactions