Time Nick Message 00:19 lhofhansl GreenXenith: Are you going to work more on water reflections? I'm happy to help (if that helps) 00:21 lhofhansl 13881 ... done 00:21 GreenXenith lhofhansl: Eventually, yes, but I have other priorities at the moment. That is a large project (still some artifacts to fix, performance to improve, and a basic generic material API to implement rather than adding yet another opinionated shader) 01:01 MTDiscord sfan5: Would you be ok with this workaround, only enabled for mingw: have a wrapper class for the LogStream's that allocates them using "new", and has no destructor. Instead, they are deallocated (and replaced with a dummy stream that does nothing) in Thread::threadProc right before the thread terminates. 01:03 MTDiscord Only a pointer to the LogStream is stored via thread_local 01:09 MTDiscord actually, better than a dummy stream, could use a non-tls mutex-protected stream (in case something logs in a destructor called during thread exit) 01:10 MTDiscord Arguably, it should be doing that already anyway, since there's no way to guarantee deconstruction order 01:12 MTDiscord *destruction order 01:40 lhofhansl GreenXenith: If you have a patch that works outside of the giant "bfs" branch, I am happy to give it a try. 01:40 lhofhansl Re: Windows. The MSVC builds seem fine. In fact this is the first time that Minetest runs well on Windows on modern hardware. Exciting! 01:41 GreenXenith I dont at the moment, but ill make a separate branch for that some time soon 10:36 sfan5 @paradust a bit hard to guarantee that only threads that go via our Thread class use logging (e.g. library use), no? 10:53 grorp btw, regarding giving games a say on touchscreen controls: #14087 10:54 ShadowBot https://github.com/minetest/minetest/issues/14087 -- Touchscreen: Allow mods to swap the meaning of short and long taps by grorp 10:54 grorp wrong channel. I'm really bad at IRC. 11:50 MTDiscord @paradust 12:26 MTDiscord sfan5: Is it hard to prevent that? A library would have to 1) create it's own thread, 2) invoke user-provided callbacks in that thread, and 3) the user-provided callback we provide it uses the logging system 12:26 MTDiscord We could add an assert to detect if this is happening, by having the constructor for LogStream check a tls variable that is only set to true in Thread class in threads. 14:10 sfan5 hmm, right 14:11 sfan5 I'm kind of tempted to go with the "seems to work" fix (my patch earlier) rather than your proposal 14:11 sfan5 but yeah yours is fine too 14:52 MTDiscord are you sure that patch works? I don't see why it would 14:52 MTDiscord in my testing, just accessing "this" inside ~LogStream caused a crash 14:53 MTDiscord also, for some reason, it almost never crashes unless i'm running it under gdb 14:54 MTDiscord not sure why that would make it more likely. maybe it's a race condition 15:05 sfan5 there's no logical reason why it should work, probably by accident 15:05 sfan5 it works for me though 15:05 sfan5 potentially the memory is already zero'ed so `delete` "works" fine 15:08 [MTMatrix] hey everyone, is there a particular way of using sound groups? 'cause, according to the docs, having three sound files named ".0/1/2.ogg" should make so that MT chooses a random one between those three, but it doesn't seem to be working... 15:09 MTDiscord That's more of a non-dev channel question. And they always worked fine for me, as long as the sound spec you use is just the "" part without any extensions. 15:11 [MTMatrix] oh ok, I thought it was the right room since the room description says "modding discussion is on-topic" 15:19 MTDiscord It's the other room that says that. I'm not sure what bridge you're using (the ones I see on the matrix side seem to be down) but it sounds like the topics aren't synced right then. 19:21 MTDiscord sfan5: I figured out why your fix works. sizeof(std::ostream) is 272 bytes on mingw64 (way larger than I thought!). Allocating them separately shrinks LogStream quite a bit. If I apply your patch but also increase BUFFER_LENGTH from 256 to 784, it starts crashing again 19:22 MTDiscord So because LogStream is so large, it is likely to eventually cross a page boundary. Which makes it more likely that the out-of-order deallocation will unmap the page it is on. 20:39 MTDiscord After making a fix, it crashes for an entirely different reason. \o/ 20:41 MTDiscord uninit_common is registered via atexit() near the beginning of main. This calls httpfetch_cleanup which uses verbosestream. 20:42 MTDiscord But the destructor for verbosestream is called before atexit calls this 20:46 MTDiscord This wasn't breaking before because the destructor was mostly trivial, it only breaks m_stream and m_dummy_stream which aren't used normally 20:47 MTDiscord but when I moved the entire LogStream into an allocation, and destroy it for real, now it crashes 20:50 MTDiscord this should really be using RAII anyway instead of atexit 22:24 sfan5 huh 22:25 sfan5 fwiw std::ostream is 272 bytes on my linux machine too 22:26 sfan5 I guess we should replace atexit with an explicit call in main() 22:27 sfan5 (pahole -> https://0x0.st/HgfP.txt but for some reason it can't detect the size of std::ostream, but the "hole" is exactly 272B) 22:42 MTDiscord even with my fix to the log stuff, there are additional crashes due to tls weirdness 22:43 MTDiscord this one crashes, much more rarely: https://github.com/minetest/minetest/blob/master/src/client/tile.cpp#L515 22:43 MTDiscord in the destructor 22:56 MTDiscord https://0x0.st/Hgfe.txt 23:26 sfan5 unfortunate 23:38 MTDiscord Is the official windows release compiled using mingw or msvc? 23:39 MTDiscord Apparently Clang can be used as an alternative compiler inside MSVC. I wonder if that would be much better