constant random crash

[littleblack111]

trafficstars

#0  0x00007f3d9ac253d8 in abort () at /usr/lib64/libc.so.6
#1  0x00005c34f21ead21 in ??? ()
#2  0x00007f3d9ac422b0 in <signal handler called> () at /usr/lib64/libc.so.6
#3  0x00007f3d9ac9d968 in __lll_lock_wait_private () at /usr/lib64/libc.so.6
#4  0x00007f3d9acb1b42 in ??? () at /usr/lib64/libc.so.6
#5  0x00007f3d9acfc93c in fork () at /usr/lib64/libc.so.6
#6  0x00005c34f2259187 in ??? ()
#7  0x00005c34f22625cc in NCrashReporter::createAndSaveCrash(int) ()
#8  0x00005c34f21ee464 in ??? ()
#9  0x00007f3d9ac422b0 in <signal handler called> () at /usr/lib64/libc.so.6
#10 0x00007f3d9aca2cfc in pthread_kill () at /usr/lib64/libc.so.6
#11 0x00007f3d9ac4217e in raise () at /usr/lib64/libc.so.6
#12 0x00007f3d9ac2535c in abort () at /usr/lib64/libc.so.6
#13 0x00007f3d9ac2639d in ??? () at /usr/lib64/libc.so.6
#14 0x00007f3d9acad0e5 in ??? () at /usr/lib64/libc.so.6
#15 0x00007f3d9acaf4ec in ??? () at /usr/lib64/libc.so.6
#16 0x00007f3d9acaf78f in ??? () at /usr/lib64/libc.so.6
#17 0x00007f3d9acb255d in free () at /usr/lib64/libc.so.6
#18 0x00005c34f221262b in ??? ()
#19 0x00005c34f2281fa6 in Debug::log(eLogLevel, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
#20 0x00007f3d3013f206 in CHighresHandler::update (this=0x5c35291e6c08) at ./src/highres.cpp:64
        PENABLED = 0x5c3528b98780
        PUSEHYPRCURSOR = 0x5c3525ee93a0
        PSIZE = 0x5c3528b99080
        PSHAKE_BASE = 0x5c3528b915f0
        PSHAKE = 0x5c3528b93600
        name = ""
        size = 216
        fut = {<std::__basic_future<Hyprutils::Memory::CUniquePointer<Hyprcursor::CHyprcursorManager> >> = {<std::__future_base> = {<No data fields>}, _M_state = std::shared_ptr<class std::__future_base::_State_baseV2> (use count -1207571712, weak count -1) = {get() = 0x5c3525eb37f0}}, <No data fields>}
#21 0x00007f3d300f7606 in CDynamicCursors::updateTheme (this=0x5c35291e6c00) at ./src/cursor.cpp:388
#22 0x00007f3d3014cf79 in hkUpdateTheme (thisptr=0x5c352896b010) at ./src/main.cpp:79
#23 0x00005c34f233f31b in ??? ()
#24 0x00005c34f233f0a6 in CHookSystemManager::emit(std::vector<SCallbackFNPtr, std::allocator<SCallbackFNPtr> >*, SCallbackInfo&, std::any) ()
#25 0x00005c34f2243d9f in CConfigManager::performMonitorReload() ()
#26 0x00005c34f223ec77 in CConfigManager::postConfigReload(Hyprlang::CParseResult const&) ()
#27 0x00005c34f223ef3b in CConfigManager::reload() ()
#28 0x00005c34f23b15d0 in ??? ()
#29 0x00007f3d9c4b8732 in ??? () at /usr/lib64/libwayland-server.so.0
#30 0x00007f3d9c4b9509 in wl_display_run () at /usr/lib64/libwayland-server.so.0
#31 0x00005c34f23b32af in CEventLoopManager::enterLoop() ()
#32 0x00005c34f219a2b2 in main ()
#0  0x000074e1e78a2cfc in ?? ()
No symbol table info available.
#1  0x0000000000000000 in ?? ()
No symbol table info available.
warning: Error detected on fd 0
error detected on stdin
#0  0x00007b02f78253d8 in ?? ()
No symbol table info available.
#1  0x00ea00ad007d0067 in ?? ()
No symbol table info available.
#2  0x0000000000000020 in ?? ()
No symbol table info available.
#3  0x0000000000000000 in ?? ()
No symbol table info available.

[im-trisha]

Same issue, i get this log constantly before i crash most of the times, idk if its related:

[ERR] ... hyprcursor for dynamic cursors failed loading theme 'bibata', falling back to pixelated trash.

[im-trisha]

p.s. i don't want to be that guy, I don't know enough about the codebase but it seems like a problem with that smart pointer having a really negative count

[VirtCode]

yeah it looks very suspicious haha

I assume the crash happens on plugin load? And is that log line being spammed or is it just always being printed before the crash?

[im-trisha]

@VirtCode wow, really fast reply well for more context (for me):

• The crash happens randomly in the session, not on plugin load (at least, never happened to me on load after using the plugin for 50 or more sddm logins)
• The few times i was able to retrieve the logs (lets say, 20 crashes-7 logs) there were some hyprland errors (way before the last log), but the one before the last one was always the pixelated trash log
• The one and only time i took the coredump it was kinda messy, but it was pretty similar to op's log (cant be sure, i dont have debug enabled)
• My 6th sense says that it has something to do with shake to magnify, because in one occurrence i had to do a specific task (screenshot with win+shift+s, win+2 to change workspace and ctrl+v), and it constantly crashed a moment before switching the workspace (probably the screenshot area selection was fast enough to trigger my 2 second treshold for shake, and for some obscure reason the crash occured 3 or 4 times in a row

I want to be clear, its not shake to find in itself the problem, as i can use it no problem, but it could cause the issue (idk if im being clear).

I just disabled shake to find, will tell you if the error occurs again

[im-trisha]

Another p.s., THE LOG I SENT COULD MEAN NOTHING!! I just associated the crash with that error, thats all. Could be completely unrelated

[littleblack111]

@VirtCode wow, really fast reply well for more context (for me): -The crash happens randomly in the session, not on plugin load (at least, never happened to me on load after using the plugin for 50 or more sddm logins)

• The few times i was able to retrieve the logs (lets say, 20 crashes-7 logs) there were some hyprland errors (way before the last log), but the one before the last one was always the pixelated trash log
• The one and only time i took the coredump it was kinda messy, but it was pretty similar to op's log (cant be sure, i dont have debug enabled)
• My 6th sense says that it has something to do with shake to magnify, because in one occurrence i had to do a specific task (screenshot with win+shift+s, win+2 to change workspace and ctrl+v), and it constantly crashed a moment before switching the workspace (probably the screenshot area selection was fast enough to trigger my 2 second treshold for shake, and for some obscure reason the crash occured 3 or 4 times in a row

I want to be clear, its not shake to find in itself the problem, as i can use it no problem, but it could cause the issue (idk if im being clear).

I just disabled shake to find, will tell you if the error occurs again

My crash is also similar, it does not crash at plugin load but at random times

[VirtCode]

hmm... I can't really seem to reproduce it on my end at all. The crash is most likely caused by some sort of race condition or something when the plugin is loading the high-resolution cursor theme in an async future. So if you want to temporarily stop the crashes, disabling hyprcursor in this plugin would probably be a workaround.

If someone could get another backtrace if the crash happens again, that would be much appreciated, just to compare with the above one. @littleblack111 what exact plugin version is that bt from you posted above, is it latest git?

Also, do you both not use a hyprcursor theme and don't have one installed?

[im-trisha]

@VirtCode hello, im pretty sure i use latest git, i do use an hyprcursor theme (bibata) I will try to send you a coredump/stacktrace asap

[littleblack111]

gdb.txt

this above crash happend when im disabling hyprcursor

Also, do you both not use a hyprcursor theme and don't have one installed?

i'm pretty sure i'm using a hyprcursor cursor theme, as the shake's scale is pretty highres(compared to hyprcursor disabled in plugin settings)

The crash is most likely caused by some sort of race condition or something when the plugin is loading the high-resolution cursor theme in an async future

the crash happens very randomly, even if the mouse isn't moving at all, especially during AFK, although it also does happen when I'm using it

[littleblack111]

gdb.txt

a.txt

more crash logs(even with hyprcursor disabled)

[VirtCode]

Thanks for the bts. It is weird that the crash occurs on a log statement. Maybe the logger doesn't really like being used from multiple threads (probably there's a reason vaxry explicitly discourages multi threading in plugins in the wiki lol).

Could someone try this patch and see whether the crashes still happen? no-async-logs.txt Don't have the highest confidence that this'll do anything but worth a try.

[im-trisha]

@VirtCode sorry, how should i try that patch? You linked a git diff it seems

[littleblack111]

Thanks for the bts. It is weird that the crash occurs on a log statement. Maybe the logger doesn't really like being used from multiple threads (probably there's a reason vaxry explicitly discourages multi threading in plugins in the wiki lol).

Could someone try this patch and see whether the crashes still happen? no-async-logs.txt Don't have the highest confidence that this'll do anything but worth a try.

yea multithreaded debuging is annoying, i think you'd have to manually switch thread and get the bt for the respective ones. anyways, the patch seems to just comment out debug logs?

[VirtCode]

yup, that is intended. When I look at the bts you sent the crash is happening on line 64 in the highres handler, which is a log statement. So the crash seems to be somewhere in there. I don't think the implementation of hyprland's logger is really made with multiple threads in mind so I thought maybe using the logger from the async closure leaves something in an undefined state, which then trips up when using the logger again (from the main thread then).

But as I said, maybe this an entirely stupid thought. But other than that I don't see anything interresting in the bt. I can't really make sense shared ptr with the negative refs that is printed in the future, as the crash happens before that is even initialized. Would help a lot if I could reproduce locally, but I really don't seem able to.

sorry, how should i try that patch? You linked a git diff it seems

Yeah, you should be able to pipe that into git apply. I.e. clone this repo locally, apply the patch, (make sure to unload the original plugin) and build and load the plugin with make load

[littleblack111]

I don't think the implementation of hyprland's logger is really made with multiple threads in mind so I thought maybe using the logger from the async closure leaves something in an undefined state, which then trips up when using the logger again (from the main thread then).

hmm it seems like they're using mutexes in the logger so i think it's thread safe?

will test the patch later

I can't really make sense shared ptr with the negative refs that is printed in the future, as the crash happens before that is even initialized.

huh, i dont understand, what does it mean by shared ptr with negative refs? don't the shared ptr get destoryed when theres no more ref/count to it?

[VirtCode]

Oh right, how did I not spot that before. Hmm, then this patch is probably useless, you're right.

huh, i dont understand, what does it mean by shared ptr with negative refs? don't the shared ptr get destoryed when theres no more ref/count to it?

I meant this line in the bt:

fut = {<std::__basic_future<Hyprutils::Memory::CUniquePointer<Hyprcursor::CHyprcursorManager> >> = {<std::__future_base> = {<No data fields>}, _M_state = std::shared_ptr<class std::__future_base::_State_baseV2> (use count -1207571712, weak count -1) = {get() = 0x5c3525eb37f0}}, <No data fields>}

it shows a shared ptr with a negative use count. But at the point the crash is (line 64), the future hasn't even been defined yet, so I am guessing this is just uninitialized memory at this point. So probably not really important.

[VirtCode]

Could you try to get a bt from a hyprland debug build? This way we'd probably see the line numbers in the bt which could give us further clues what's actually going wrong in that log call.

[im-trisha]

@VirtCode Hello, I dont get this log anymore when i disabled the shake to find... I'll try enabling it again

[littleblack111]

Could you try to get a bt from a hyprland debug build? This way we'd probably see the line numbers in the bt which could give us further clues what's actually going wrong in that log call.

Sorry I can't really do that now or in a few weeks, can @im-trisha try?

[VirtCode]

Can any of you still reproduce these crashes on 0.49.0 or latest -git?

[littleblack111]

nope seems to fixed now thanks

On Wed, 25 Jun 2025 at 05:15, Virt @.***> wrote:

VirtCode left a comment (VirtCode/hypr-dynamic-cursors#74) https://github.com/VirtCode/hypr-dynamic-cursors/issues/74#issuecomment-3001881938

Can any of you still reproduce these crashes on 0.49.0 or latest -git?

— Reply to this email directly, view it on GitHub https://github.com/VirtCode/hypr-dynamic-cursors/issues/74#issuecomment-3001881938, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXJF2SOVY25Z7EL3OSWICND3FG5W3AVCNFSM6AAAAAB3V4HM52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAMBRHA4DCOJTHA . You are receiving this because you were mentioned.Message ID: @.***>

[im-trisha]

Same here! Thanks

[VirtCode]

Great, let's just hope it's gone for good. I'll close this then. Please reopen if the issue surfaces again.