| 2022-06-16 00:07:48 +0000 | hipurus | (~Guest9@184.4.83.175) (Quit: Client closed) |
| 2022-06-16 00:15:07 +0000 | werneta | (~werneta@137.79.230.15) (Ping timeout: 260 seconds) |
| 2022-06-16 00:16:52 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-06-16 00:21:10 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-06-16 00:21:54 +0000 | werneta | (~werneta@137.79.230.15) |
| 2022-06-16 00:26:38 +0000 | stackdroid18 | (~stackdroi@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-06-16 01:00:22 +0000 | benin | (~benin@183.82.27.33) (Ping timeout: 246 seconds) |
| 2022-06-16 01:02:43 +0000 | benin | (~benin@183.82.204.191) |
| 2022-06-16 01:53:40 +0000 | vrs_ | vrs |
| 2022-06-16 01:56:27 +0000 | <byorgey> | geekosaur: ms teams for linux works fine for me under xmonad |
| 2022-06-16 01:56:52 +0000 | ocelot__ | (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) |
| 2022-06-16 01:56:59 +0000 | <byorgey> | I mean, it doesn't seem any crappier than it would be under any other window manager |
| 2022-06-16 01:58:15 +0000 | ocelot__ | (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) (Client Quit) |
| 2022-06-16 01:58:32 +0000 | ocelot_ | (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) (Remote host closed the connection) |
| 2022-06-16 01:59:01 +0000 | ocelot_ | (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) |
| 2022-06-16 01:59:31 +0000 | ocelot_ | (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) (Client Quit) |
| 2022-06-16 02:00:12 +0000 | ocelot_ | (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) |
| 2022-06-16 02:02:32 +0000 | banc | (banc@gateway/vpn/airvpn/banc) (Ping timeout: 248 seconds) |
| 2022-06-16 02:10:33 +0000 | td_ | (~td@muedsl-82-207-238-033.citykom.de) (Ping timeout: 256 seconds) |
| 2022-06-16 02:12:32 +0000 | td_ | (~td@muedsl-82-207-238-107.citykom.de) |
| 2022-06-16 02:23:20 +0000 | banc | (banc@gateway/vpn/airvpn/banc) |
| 2022-06-16 02:30:41 +0000 | benin | (~benin@183.82.204.191) (Ping timeout: 246 seconds) |
| 2022-06-16 03:19:49 +0000 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) |
| 2022-06-16 04:07:58 +0000 | mvk | (~mvk@2607:fea8:5ce3:8500::4588) |
| 2022-06-16 06:07:39 +0000 | sundbry | (~quassel@99-42-143-129.lightspeed.sntcca.sbcglobal.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-06-16 07:10:33 +0000 | dschrempf | (~dominik@mobiledyn-62-240-134-11.mrsn.at) |
| 2022-06-16 07:33:20 +0000 | jaklt[m] | (~jaklttchn@2001:470:69fc:105::a42) |
| 2022-06-16 08:08:25 +0000 | benin | (~benin@183.82.28.222) |
| 2022-06-16 08:39:52 +0000 | defjam | (~eb0t@33bac70c.skybroadband.com) (Ping timeout: 248 seconds) |
| 2022-06-16 08:41:51 +0000 | defjam | (~eb0t@33bac63e.skybroadband.com) |
| 2022-06-16 08:48:59 +0000 | fdnick` | (~user@2a02:8109:a140:e0a:cf84:f4c7:382a:dcd8) |
| 2022-06-16 09:00:09 +0000 | kwer[m] | (~kwermatri@2001:470:69fc:105::1:4da1) (Quit: You have been kicked for being idle) |
| 2022-06-16 09:00:16 +0000 | jmac123[m] | (~jmac123ma@2001:470:69fc:105::1:eaf0) (Quit: You have been kicked for being idle) |
| 2022-06-16 09:12:15 +0000 | gdd | (~gdd@2001:470:1f13:187:c211:ee4c:6eca:b634) |
| 2022-06-16 09:38:08 +0000 | fdnick`` | (~user@2a02:8109:a140:e0a:273f:3891:babf:2556) |
| 2022-06-16 09:41:30 +0000 | dschrempf | (~dominik@mobiledyn-62-240-134-11.mrsn.at) (Quit: WeeChat 3.5) |
| 2022-06-16 09:42:13 +0000 | fdnick` | (~user@2a02:8109:a140:e0a:cf84:f4c7:382a:dcd8) (Ping timeout: 258 seconds) |
| 2022-06-16 09:47:45 +0000 | alternateved | (~alternate@194.99.105.235) |
| 2022-06-16 10:05:19 +0000 | alternateved | (~alternate@194.99.105.235) (Read error: Connection reset by peer) |
| 2022-06-16 10:05:45 +0000 | alternateved | (~alternate@194.99.105.235) |
| 2022-06-16 10:14:58 +0000 | fdnick`` | (~user@2a02:8109:a140:e0a:273f:3891:babf:2556) (ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)) |
| 2022-06-16 11:14:59 +0000 | mvk | (~mvk@2607:fea8:5ce3:8500::4588) (Ping timeout: 258 seconds) |
| 2022-06-16 11:43:52 +0000 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 2022-06-16 12:07:18 +0000 | benin | (~benin@183.82.28.222) (Quit: The Lounge - https://thelounge.chat) |
| 2022-06-16 12:24:18 +0000 | dschrempf | (~dominik@mobiledyn-62-240-134-11.mrsn.at) |
| 2022-06-16 12:42:07 +0000 | SevenCircle[m] | (~sevencirc@2001:470:69fc:105::2:2ee4) |
| 2022-06-16 14:32:17 +0000 | dschrempf | (~dominik@mobiledyn-62-240-134-11.mrsn.at) (Quit: WeeChat 3.5) |
| 2022-06-16 16:02:10 +0000 | mvk | (~mvk@2607:fea8:5ce3:8500::4588) |
| 2022-06-16 16:14:26 +0000 | stackdroid18 | (14094@user/stackdroid) |
| 2022-06-16 16:54:54 +0000 | neoatnebula | (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) |
| 2022-06-16 16:55:26 +0000 | neoatnebula | (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) (Client Quit) |
| 2022-06-16 16:56:05 +0000 | neoatnebula | (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) |
| 2022-06-16 17:27:22 +0000 | neoatnebula | (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) (Quit: Client closed) |
| 2022-06-16 17:46:41 +0000 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 2022-06-16 17:49:32 +0000 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-06-16 18:04:53 +0000 | <lyiriyah[m]> | Hi, I have an odd issue. |
| 2022-06-16 18:04:53 +0000 | <lyiriyah[m]> | There's a discrepancy |
| 2022-06-16 18:05:16 +0000 | <lyiriyah[m]> | * a discrepancy between the window name shown in xmobar and the window name shown in _NET_WM_NAME by `xprop`. |
| 2022-06-16 18:06:21 +0000 | <geekosaur> | _NET_WM_NAME changes dynamically and doesn't typically force the logHook to be rerun |
| 2022-06-16 18:07:00 +0000 | <geekosaur> | (this can also affect taskbars and such unless they specifically watch _NET_WM_NAME) |
| 2022-06-16 18:07:46 +0000 | <lyiriyah[m]> | Oh wait, I see what's happening. The title's being read from WM_CLASS |
| 2022-06-16 18:07:57 +0000 | <lyiriyah[m]> | Is there any way to change this somehow? |
| 2022-06-16 18:08:25 +0000 | <lyiriyah[m]> | It's slightly annoying because all my librewolf windows have the same name... |
| 2022-06-16 18:08:51 +0000 | <geekosaur> | huh? you should doublecheck your logHook in that case |
| 2022-06-16 18:12:34 +0000 | <lyiriyah[m]> | I don't have a logHook configured, I'm using X.H.StatusBar |
| 2022-06-16 18:13:50 +0000 | lyiriyah[m] | sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/2e47fc4a6a03a22616085d8bb259ab616795… |
| 2022-06-16 18:19:44 +0000 | <geekosaur> | what's `ppC`? |
| 2022-06-16 18:19:58 +0000 | <lyiriyah[m]> | My ppConfig |
| 2022-06-16 18:21:05 +0000 | <geekosaur[m]> | right, but what is its value? |
| 2022-06-16 18:21:29 +0000 | <lyiriyah[m]> | One sec |
| 2022-06-16 18:24:31 +0000 | lyiriyah[m] | sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/f988ad70f0c2af276979ab959e0847972a01… |
| 2022-06-16 18:25:16 +0000 | <lyiriyah[m]> | According to the source the default value of `ppTitle` is `shorten 80` |
| 2022-06-16 18:32:44 +0000 | <lyiriyah[m]> | X.L.Tabbed has the same issue which leads me to believe it's something going wrong in X.U.NamedWindows |
| 2022-06-16 18:32:48 +0000 | <geekosaur[m]> | it uses `getName`, not `getNameWMClass`. `getName` does the right thing unless you've used `NamedWindow` to rename it |
| 2022-06-16 18:33:42 +0000 | <geekosaur[m]> | thing is, I get the window title and use Tabbed here, and both behave correctly |
| 2022-06-16 18:33:48 +0000 | <geekosaur[m]> | xmonad git |
| 2022-06-16 18:34:14 +0000 | <lyiriyah[m]> | Hmm, odd |
| 2022-06-16 18:38:14 +0000 | <lyiriyah[m]> | It's definitely reading `WM_CLASS`. Changing that property with `xdotool selectwindow set_window --classname "test"` also changes the title |
| 2022-06-16 18:38:53 +0000 | <geekosaur[m]> | you don't happen to have a `lib` subdirectory in your xmonad configuration, do you? |
| 2022-06-16 18:39:05 +0000 | <lyiriyah[m]> | No, I don't |
| 2022-06-16 18:41:31 +0000 | <geekosaur[m]> | (you can override xmonad modules there, including XMonad.Util.NamedWindow, and I've been known to do that for development or debugging and then forget about it 😀) |
| 2022-06-16 18:41:39 +0000 | <lyiriyah[m]> | Ah |
| 2022-06-16 18:42:47 +0000 | <lyiriyah[m]> | I do have a build script:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ef55ff986e8eec820c89cd40474f18f1c9f4…) |
| 2022-06-16 18:43:28 +0000 | <geekosaur[m]> | it shouldn't unless you also have a possibly customized xmonad-contrib source tree around |
| 2022-06-16 18:43:56 +0000 | <lyiriyah[m]> | I do have a contrib source tree but I haven't customised it |
| 2022-06-16 18:44:18 +0000 | <geekosaur[m]> | actually I wonder if you even need that build script these days, we support stack config directly as long as a stack.yaml is present, which you'd need for that to work anyway |
| 2022-06-16 18:44:54 +0000 | <lyiriyah[m]> | Don't think I do -- it's just a holdover from older configs |
| 2022-06-16 18:46:34 +0000 | <geekosaur[m]> | you might verify the local contrib source tree isn't in use, or if it is, that NamedWindows.hs hasn't been edited |
| 2022-06-16 18:49:16 +0000 | <lyiriyah[m]> | It hasn't been edited, no |
| 2022-06-16 18:59:10 +0000 | <geekosaur[m]> | I can't help but think that `getNameWMClass` being right next to `getName` is related, but I'd be really concerned if this is a link error of some kind |
| 2022-06-16 19:01:51 +0000 | <lyiriyah[m]> | Yeah... |
| 2022-06-16 19:03:57 +0000 | <geekosaur[m]> | poking around locally and mine is definitely working correctly. are you on 0.17.0 or git? |
| 2022-06-16 19:04:03 +0000 | <lyiriyah[m]> | git |
| 2022-06-16 19:05:47 +0000 | <geekosaur[m]> | I traced through git's code and it's correct. sigh |
| 2022-06-16 19:06:13 +0000 | <geekosaur[m]> | didn't get broken by the rewrite to simplify status bar support or anything like that |
| 2022-06-16 19:11:35 +0000 | <geekosaur[m]> | don't suppose Solid is about by any chance? |
| 2022-06-16 19:13:45 +0000 | <geekosaur[m]> | hm. what version of ghc? we've been having some weird problems with 9.0.1 and later, although if this turns out to be related then things are much worse than anyone imagined… |
| 2022-06-16 19:14:08 +0000 | <lyiriyah[m]> | 8.10.7 |
| 2022-06-16 19:14:42 +0000 | <lyiriyah[m]> | Wait, that's `ghc --version`, `stack ghc -- --version` gives me 9.0.2 |
| 2022-06-16 19:16:02 +0000 | <geekosaur[m]> | just for grins and giggles, try seeing if it happens with 8.10.7 (change the resolver to lts 18.28) |
| 2022-06-16 19:17:13 +0000 | <lyiriyah[m]> | Alright, rebuilding now |
| 2022-06-16 19:20:12 +0000 | <Solid> | geekosaur[m]: am here, what's up? |
| 2022-06-16 19:20:59 +0000 | <Solid> | guess I should read the backlog :) |
| 2022-06-16 19:21:30 +0000 | <lyiriyah[m]> | I'm having an issue where X.U.NamedWindows is reading window titles from WM_CLASS instead of _NET_WM_NAME or WM_NAME |
| 2022-06-16 19:22:18 +0000 | <lyiriyah[m]> | Solid |
| 2022-06-16 19:22:56 +0000 | <geekosaur> | I've been through the code several times and it seems to be doing the right thing, plus it's working properly here. was wondering if you might have some additional ideas |
| 2022-06-16 19:24:41 +0000 | <geekosaur[m]> | (sorry for jumping between irc and matrix, had a potential problem to deal with in another channel) |
| 2022-06-16 19:25:07 +0000 | <Solid> | lyiriyah[m]: could you post your entire config? I'd like to first see if I can actually reproduce this |
| 2022-06-16 19:25:11 +0000 | stackdroid18 | (14094@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 2022-06-16 19:26:15 +0000 | <lyiriyah[m]> | https://git.envs.net/lyiriyah/xmonad-config/src/branch/zenbook-duo/xmonad.hs |
| 2022-06-16 19:31:38 +0000 | <Solid> | mh, still building, but I can see that getName _does_ call getClassHint in case everything else (_NET_WM_NAME and WM_CLASS, that is) fails |
| 2022-06-16 19:32:18 +0000 | <geekosaur[m]> | except it shouldn't be failing, since it works with xprop |
| 2022-06-16 19:33:14 +0000 | <geekosaur[m]> | mrr, I really hope this doesn't turn out to be the same problem as #389 |
| 2022-06-16 19:33:28 +0000 | <geekosaur[m]> | if it goes away with 8.10.7 we got a definite ghc hot potato |
| 2022-06-16 19:34:04 +0000 | <geekosaur[m]> | problem with FFI most likely |
| 2022-06-16 19:35:13 +0000 | <Solid> | I run 9.0.2 myself and it's totally fine here |
| 2022-06-16 19:35:19 +0000 | <Solid> | so probably not the GHC thing |
| 2022-06-16 19:36:05 +0000 | <geekosaur[m]> | keep in mind I couldn't reproduce the crash locally with my config and 9.2.2, and you'd think if any config would provoke it, it'd be my monstrosity |
| 2022-06-16 19:36:27 +0000 | <lyiriyah[m]> | I've rebuilt with 8.10.7 and it's still occuring |
| 2022-06-16 19:36:35 +0000 | <lyiriyah[m]> | s/occuring/occurring/ |
| 2022-06-16 19:36:38 +0000 | <geekosaur[m]> | while abastro reproduced it with a near minimal config |
| 2022-06-16 19:36:54 +0000 | <geekosaur[m]> | I'm not sure if that's good news or bad |
| 2022-06-16 19:37:05 +0000 | <Solid> | (I could actually reproduce that today (at some point, right now it's stable again ._.) but I also had to play around with xft stuff) |
| 2022-06-16 19:38:02 +0000 | <Solid> | lyiriyah[m]: I guess your best bet would be to play around with getName and getNameWmClass in a stack ghci session or something and perhaps print the exception that occurs |
| 2022-06-16 19:41:22 +0000 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 2022-06-16 19:43:40 +0000 | terrorjack | (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 2022-06-16 19:46:27 +0000 | <lyiriyah[m]> | <Solid> "lyiriyah: I guess your best..." <- Can you give me some pointers on how I'd go about this? |
| 2022-06-16 19:48:54 +0000 | <geekosaur[m]> | that'll be difficult because it's in X, not IO |
| 2022-06-16 19:49:01 +0000 | <geekosaur[m]> | not even MonadIO |
| 2022-06-16 19:52:40 +0000 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) |
| 2022-06-16 19:55:36 +0000 | <lyiriyah[m]> | hmm |
| 2022-06-16 20:00:48 +0000 | <Solid> | I would just copy the relevant parts out of getName |
| 2022-06-16 20:01:04 +0000 | <Solid> | all you need is to call openDisplay, really |
| 2022-06-16 20:01:28 +0000 | <Solid> | all the rest is X11 functions that are in IO natively |
| 2022-06-16 20:01:33 +0000 | gdd | (~gdd@2001:470:1f13:187:c211:ee4c:6eca:b634) (Remote host closed the connection) |
| 2022-06-16 20:03:30 +0000 | <Solid> | I wish I could offer a few more pointers (heh) but I'm dead tired and will go to bed now |
| 2022-06-16 20:03:43 +0000 | <lyiriyah[m]> | Good night |
| 2022-06-16 20:14:45 +0000 | <geekosaur[m]> | oh god, I hope I haven't just found it |
| 2022-06-16 20:15:50 +0000 | <geekosaur[m]> | `getTextProperty`, when I chased it down, uses a `CString`. which has a trailing `NUL`. but X11 properties are counted strings |
| 2022-06-16 20:17:15 +0000 | <geekosaur[m]> | which means (a) we usually get lucky with trailing `NUL`s (b) we probably poke a `NUL` where it doesn't belong, which would explain GC crashes |
| 2022-06-16 20:18:11 +0000 | <lyiriyah[m]> | Any idea how I could see if this is the issue? |
| 2022-06-16 20:20:06 +0000 | <geekosaur[m]> | not easily. I need to doublecheck that something that is a `CString` is assumed to have trailing `NUL`. but I'm pretty sure there's a separate `CStringLen` for this case |
| 2022-06-16 20:31:53 +0000 | <geekosaur[m]> | mm, looks like it's okay aside from not being thread safe (and nobody allocates or frees the string so it must be internal, which makes me wonder if there's a length limit…) |
| 2022-06-16 20:32:19 +0000 | <geekosaur[m]> | wonder if we should switch to the raw property interface so we have control over that |
| 2022-06-16 20:35:27 +0000 | <geekosaur[m]> | `openDisplay [] >>= \d -> getTextProperty d `_windowid_`"_NET_WM_NAME" >>= print . tp_value` where _windowid_ comes from xwininfo |
| 2022-06-16 20:36:38 +0000 | <geekosaur[m]> | assuming a `CString` has a `Show` instance |
| 2022-06-16 20:37:26 +0000 | <geekosaur[m]> | (wat, why does this think I changed X11) |
| 2022-06-16 20:37:53 +0000 | <geekosaur[m]> | oh, wrong directory 👀 |
| 2022-06-16 20:39:19 +0000 | <geekosaur[m]> | and I think that needs to be an Atom, not a string |
| 2022-06-16 20:39:45 +0000 | <geekosaur[m]> | yep |
| 2022-06-16 20:43:28 +0000 | <geekosaur[m]> | well, that "worked" but the Show instance just prints the pointer. not real helpful |
| 2022-06-16 20:45:43 +0000 | <geekosaur[m]> | *Main Foreign.C.String> openDisplay [] >>= \d -> internAtom d "_NET_WM_NAME" False >>= \a -> getTextProperty d 0x400001f a >>= peekCString . tp_value >>= print |
| 2022-06-16 20:45:43 +0000 | <geekosaur[m]> | "Element [2] | xmonad - Google Chrome" |
| 2022-06-16 20:47:36 +0000 | lyiriyah[m] | sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/3753f1e3a3e363a76fd797aee04d75021822… |
| 2022-06-16 20:47:46 +0000 | <lyiriyah[m]> | oh the window doesn't exist |
| 2022-06-16 20:47:50 +0000 | <lyiriyah[m]> | 🤦 |
| 2022-06-16 20:47:54 +0000 | <lyiriyah[m]> | it's been a long day |
| 2022-06-16 20:48:08 +0000 | <geekosaur[m]> | the window ID I used was for my Element app window, you need to use xwininfo to get the window ID for some window on your desktop |
| 2022-06-16 20:48:20 +0000 | <geekosaur[m]> | which I mentioned earlier |
| 2022-06-16 20:49:17 +0000 | <lyiriyah[m]> | Ok, when I actually use a window that exists that does work on my end |
| 2022-06-16 20:53:31 +0000 | <geekosaur[m]> | I still need to check that when we *set* a property we're not doing something stupid, since I'm not yet sure `NUL` is handled sanely on either the Haskell or the X11 end |
| 2022-06-16 20:53:55 +0000 | <lyiriyah[m]> | Alright |
| 2022-06-16 20:54:15 +0000 | <lyiriyah[m]> | Thanks for your help, by the way (you too Solid) |
| 2022-06-16 20:54:50 +0000 | <geekosaur[m]> | I do worry about the thread unsafeness of this stuff; I hope you aren't configured to link with `-threaded` or things may be going very wrong (although we don't use threads so they *shouldn't* be — famous last words…) |
| 2022-06-16 20:56:25 +0000 | <geekosaur[m]> | actually I think with `threaded` it may be being run in a different thread by the IO manager even if we don't make new Haskell threads, so |
| 2022-06-16 20:56:43 +0000 | <geekosaur[m]> | s/`/`-/ |
| 2022-06-16 21:00:11 +0000 | <geekosaur[m]> | mm, `XSetTextProperty` doesn't require a `NUL`, it uses `nitems`, good. |
| 2022-06-16 21:05:01 +0000 | <geekosaur[m]> | and the other side uses a `CStringLen`. we're golden |
| 2022-06-16 21:05:38 +0000 | <geekosaur[m]> | some ways I wish we weren't, though, it'd be good to find a smoking gun for all the 9.x crashes |
| 2022-06-16 21:09:44 +0000 | <geekosaur[m]> | you might have to patch NamedWindows.hs to show what's happening |
| 2022-06-16 21:16:28 +0000 | <lyiriyah[m]> | Alright, I can do that |
| 2022-06-16 21:41:50 +0000 | alternateved | (~alternate@194.99.105.235) (Remote host closed the connection) |
| 2022-06-16 21:46:09 +0000 | gdd | (~gdd@2001:470:1f13:187:49b9:231c:6a88:73db) |
| 2022-06-16 21:50:45 +0000 | Guest67 | (~Guest67@2607:fea8:7ca0:2270:6044:2b47:5cac:b70f) |
| 2022-06-16 22:48:46 +0000 | <liskin> | geekosaur[m]: the main thread is bound, and you can't fork a thread while staying inside of the X monad, and most people don't run xmonad with -threaded, so… |
| 2022-06-16 22:49:47 +0000 | <liskin> | but yeah with -threaded and manually forking a thread in IO and calling thread unsafe function that use global storage, things might go awry |
| 2022-06-16 22:50:22 +0000 | <liskin> | but then maybe the current Xlib uses thread-local storage? it certainly does use mutexes to protect its own shared data |
| 2022-06-16 22:52:58 +0000 | <geekosaur> | only if so enabled, which is a call I don't recall us making (and it slows X11 down a lot) |
| 2022-06-16 22:53:37 +0000 | <geekosaur> | but the real worry is internal state (that is, a static buffer). and we have modules which fork threads that open their own connections to the X server |
| 2022-06-16 22:54:14 +0000 | <geekosaur> | I don't offhand recall any of those calling directly or indirectly XGetTextProperty, but if any do there's one source of problems |
| 2022-06-16 22:54:33 +0000 | <geekosaur> | the other potential source is of course that presumably static buffer… and buffer overflows |
| 2022-06-16 22:54:58 +0000 | <geekosaur> | since there's no evident call to XFree anywhere, I have to assume it's static and therefore overflowable |
| 2022-06-16 22:55:42 +0000 | <geekosaur> | but I don't really want to dig into Xlib source to find out |
| 2022-06-16 23:01:22 +0000 | <geekosaur> | flip side, we've never heard of problems here before, so it either can't be too bad or is really hard to hit in most cases (but that leaves why lyiriyah[m] would be hitting it so consistently, which is some of what makes me wonder if `-threaded` might be involved) |
| 2022-06-16 23:03:56 +0000 | <liskin> | it's enabled by default since last xlib or two |
| 2022-06-16 23:04:03 +0000 | <geekosaur> | oh |
| 2022-06-16 23:04:20 +0000 | <geekosaur> | surprised I haven't heard any bitching about performance |
| 2022-06-16 23:14:13 +0000 | steve__ | (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 246 seconds) |
| 2022-06-16 23:33:39 +0000 | <geekosaur> | oh wait,m they included their build script, and no `-threaded` |
| 2022-06-16 23:34:07 +0000 | <geekosaur> | sigh. I have no clue why `getName` would be taking the fallback path through `WM_CLASS` |
| 2022-06-16 23:37:42 +0000 | Guest67 | (~Guest67@2607:fea8:7ca0:2270:6044:2b47:5cac:b70f) (Quit: Client closed) |