You are not logged in.
Hey. Yesterday everything was fine but today when I booted up my PC dwm crashed in a couple of minutes and took me to the tty. Tried it again and again and the same thing happened.
journalctl -b -e | grep dwm :
https://bpa.st/XL4Q
Thanks.
Last edited by bowlin (2025-05-26 09:48:08)
Offline
Mod note: Moving to AUR Issues.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Please don't grep, parts of the backtrace are missing.
https://wiki.archlinux.org/title/Core_d … _core_dump
Sanity check: have you tried to rebuild dwm? (chances are this is the consequence of an update?)
Offline
Sorry about that. Also tried rebuilding dwm but it made no difference, although I was able to use my system for a long time without any trouble. Until it happened again.
coredumpctl info $pid:
https://bpa.st/NEAA
Edit: Also haven't pulled any updates to my build.
Last edited by bowlin (2025-05-21 00:13:15)
Offline
Is this vanilla dwm or do you apply any patches?
Offline
I have several patches applied:
urg-border, autostart, barpadding, movestack, restartsig, vanitygaps, alwayscenter, bar-height, hide_vacant_tags, pertag and swallow.
It has worked just fine and I haven't even patched anything into it recently. Only made minor changes, mainly regarding bar padding and font etc.
Offline
Make sure to build and install the debug package for an extended backtrace and likely share your dwm.c along it.
Offline
By the debug package you're implying gdb? And the crash doesn't happen as often now. Typing in a dwm session right now.
For starters here's my dwm.c:
https://bpa.st/24MA
Offline
https://wiki.archlinux.org/title/Debuginfod
https://wiki.archlinux.org/title/Makepk … es_and_LTO
It shall get us the line of the segfault
Offline
Tinkered around for a bit with it, and this is what I got:
(gdb) bt
#0 0x000064eb8dc4ff7d in updatewmhints ()
#1 0x000064eb8dc51953 in propertynotify ()
#2 0x000064eb8dc4dd5c in main ()
Offline
You don't have to manually run gdb, the point is to have a debug enabled build to get more information than just the function.
See the links I posted (debuginfod is likely less relevant since it's a local build)
You might also want to try the vanilla dwm.c to see whether it's indeed related to your local modifications.
Offline
The latter link is related to makepkg though, no? Not sure what I need to do in terms of enabling debugging in my build. Modify the c -flags?
Also can't seem to recreate the crash anymore, don't know why.
Offline
How do you build dwm? Manually?
Add "-gdwarf" to the CFLAGS
Offline
I compile it manually: "sudo make install", the crash happened again although I didn't get to modifying the CFLAGS yet Will modify now and recompile & restart.
Edits:
Isn't "-g" enough? and I do need it by itself anyways, right?
Here's what I got: https://bpa.st/BIGQ
Also it's somehow related to opening windows or links etc. The crash happened twice in a row when I did the same thing, tried to open a new window on Steam. Switched to openbox for the time being.
Last edited by bowlin (2025-05-23 18:31:17)
Offline
#0 0x00005fc341393f7d in updatewmhints (c=0x5fc3446bd7c0) at dwm.c:2432
2432 XSetWindowBorder(dpy, c->win, scheme[SchemeUrg][ColBorder].pixel);
So eiher "c" is a dangeling pointer or the scheme[][] matrix is bogus or the index out of bounds.
And it's gonna be the urg-border patch, resp. your config.h where colors is gonna be a 2x3 matrix, not 3x3?
Offline
That went a bit over my head, but here's my config.def.h (config.h is exactly the same)
Offline
/*static const char *colors[][3] = {*/
/* fg bg border */
/*[SchemeNorm] = { col_gray3, col_gray1, col_gray2 },
[SchemeSel] = { col_gray4, col_cyan, col_cyan },
[SchemeUrg] = { col_gray4, col_cyan, col_urgborder },
};*/
#include "/home/jere/.cache/wal/colors-wal-dwm.h"
The problem will be in /home/jere/.cache/wal/colors-wal-dwm.h which likely will lack some [SchemeUrg] line?
Offline
Now that pywal got into the picture.. I just realized that I switched from the archived pywal (no longer maintained iirc) to pywal16. That might aswell be at play here. Although I'm not quite sure as to what changed, since both of them work relatively the same. Colors-wal-dwm.h should be the same on both atleast structurally as far as I now.
Edit:
Saying all of that, did a bit of digging around and it indeed seems like pywal16 handles it differently. There is a separate file (colors-wal-dwm-urg.h) for the urg patch. Those lines related to it are missing in the file I included. The pywal related instructions on github were 99% the same so I thought only minor stuff had changed.
I'll change the line to include colors-wal-dwm-urg.h instead and report back.
Offline
That seemed to be the culprit here, thanks a bunch for helping me get to the bottom of it! Now I know at the very least how to get a bit of information out of a crash dump.
Offline