Time Nick Message 10:59 [MTMatrix] Release candidate today? 11:00 rubenwardy release candidate yesterday 11:00 rubenwardy https://forum.minetest.net/viewtopic.php?t=30853 12:37 celeron55 might be worth it to write some kind of SDL2 pros/cons and future expectations statement in that forum topic. the keybinding issue is probably very weird to users without some background 12:45 celeron55 here's a draft: the situation has been that we have to get rid of irrlicht's legacy windowing and input code at some point, and now is the time, with SDL2 being the up-to-date replacement. it allows things like touchscreen input on desktop builds, and in the future full gamepad support. it causes changes to keyboard input handling. the keyboard input handling is in some ways more capable, but it 12:45 celeron55 breaks old keyboard layout specific keybinds - this is because it binds keys based on their position on the keyboard, instead of the symbol on the key 13:55 celeron55 ^ thoughts? 14:02 [MTMatrix] I can make you wait months so you know how it feels :^] 14:02 [MTMatrix] But yes, imho makes sense 14:06 celeron55 i'm good at that game, let me get back to this in 2025 :^^) 14:09 celeron55 the initial response does make me feel like a bit more workarounds to support the default keys might not hurt. but then again maybe it would hurt in the long run 14:09 celeron55 like, what does one have to say to make users accept the bit of a sting this is making 14:09 celeron55 where's the PR department 14:12 MTDiscord 🙂 14:42 MTDiscord After reading the explanation... I still am confused what the problem is. On windows, and on linux the way I do it, every time I install a new minetest version, nothing is saved that I don't manually import from the old version 14:43 MTDiscord If the keybinds have a different internal mapping... I simply wouldn't notice as long as it works 16:15 MTDiscord Update through distro repo or through flatpak, or through git by fetch/pull, checkout and build... all those methods keep everything that is user data intact. 16:23 MTDiscord Hm. yeah, it will break some players' default settings. It's not that hard to reset your keybinds again though. 16:36 MTDiscord You won't be able to make a compound keybind yet though 17:15 MTDiscord Woohoo! Now to spin up my performance testing stuff again, almost time for feature unfreeze 20:46 MTDiscord So, to be clear, it has been decided that the limiting object observers PR is not going into 5.9? 20:55 rubenwardy correct 21:28 MTDiscord For some reason installer builds don't work when the build type is Release. https://github.com/LoneWolfHT/minetest-installers-windows/raw/master/Minetest-5.9.0-win64.msi 21:29 MTDiscord Exception thrown at 0x00007FFA4CD73080 (msvcp140.dll) in minetest.exe: 0xC0000005: Access violation reading location 0x0000000000000000. 21:29 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1270493967359672390/image.png?ex=66b3e736&is=66b295b6&hm=510dd48fabfb69d308f912cea835eb4b50dccd3170691eb6ba7e66dfea8a5247& 21:30 MTDiscord That’s standard library code. Can you go up a frame? 21:31 MTDiscord Logger::registerThread in log.cpp 21:31 MTDiscord g_logger.registerThread("Main"); in main.cpp 21:33 MTDiscord Ooh a global object. Those can be uninitialized for a time at the beginning of the program. 21:33 MTDiscord Fun fun, does registerThread acquire a mutex? 21:33 MTDiscord cpp void Logger::registerThread(const std::string &name) { std::thread::id id = std::this_thread::get_id(); MutexAutoLock lock(m_mutex); m_thread_names[id] = name; } 21:34 MTDiscord I’m betting g_logger is uninitialized. 21:35 MTDiscord Thus the m_mutex field is uninitialized and the access to the lock’s member data is invalid. 21:36 MTDiscord UBSan might detect the issue, or printing from where it’s initialized and where the method gets called might show the issue as well. 21:37 MTDiscord The order in which globals get initialized across translation units is undefined and turning on optimization flags could switch it around. 21:44 MTDiscord Breakpoint before the crash 21:44 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1270497769177616394/image.png?ex=66b3eac0&is=66b29940&hm=26e23dea649c2b6898df0d3e35f0a4acdd5061de6f767f02cb68d282682a76f7& 21:45 pgimeno doesn't that mean that g_thread is in fact initialized? 21:46 pgimeno g_logger* 21:48 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1270498653030842408/image.png?ex=66b3eb93&is=66b29a13&hm=19cfeacf488a814bba172f410115ec9b4de9741bce51815b4c00945172ce9923& 21:52 MTDiscord Hmm, since it's accessed from main, it should be initialized by then, I think. 21:59 MTDiscord Yes, that's correct. 21:59 MTDiscord Or it will be initialized when its translation unit is used. So that's not the issue. 22:03 MTDiscord It looks like the address of g_thread changed between the breakpoints? 23:07 MTDiscord I'm way out of my depth at this point 23:36 MTDiscord I feel like I am, too. I haven’t run into this beginning that I recall, so I’m not recognizing the issue. 23:36 MTDiscord I hope it’s not caused by UB. I would recommend building with UBSan just to rule that out. 23:47 MTDiscord AFAIK that's not a thing Visual Studio? 23:47 MTDiscord *for Visual Studio 23:48 MTDiscord LandarVargan: How do you produce these builds? 23:48 MTDiscord Visual Studio 2022 with RUN_IN_PLACE=FALSE 23:48 MTDiscord I see an option called ASAN, I'll try that