| Time |
Nick |
Message |
| 00:06 |
|
GreenXenith joined #minetest-dev |
| 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) |
| 00:35 |
|
appguru joined #minetest-dev |
| 01:01 |
MTDiscord |
<paradust> 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 |
<paradust> Only a pointer to the LogStream is stored via thread_local |
| 01:09 |
MTDiscord |
<paradust> 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 |
<paradust> Arguably, it should be doing that already anyway, since there's no way to guarantee deconstruction order |
| 01:12 |
MTDiscord |
<paradust> *destruction order |
| 01:37 |
|
fluxionary joined #minetest-dev |
| 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 |
| 02:53 |
|
GreenXenith joined #minetest-dev |
| 04:15 |
|
GreenXenith joined #minetest-dev |
| 04:18 |
|
YuGiOhJCJ joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:23 |
|
calcul0n_ joined #minetest-dev |
| 10:16 |
|
grorp joined #minetest-dev |
| 10:19 |
|
cranez joined #minetest-dev |
| 10:26 |
|
grorp joined #minetest-dev |
| 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:43 |
|
ivanb joined #minetest-dev |
| 10:52 |
|
ivanbu joined #minetest-dev |
| 10:52 |
|
grorp joined #minetest-dev |
| 10:53 |
|
YuGiOhJCJ joined #minetest-dev |
| 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:19 |
|
imi joined #minetest-dev |
| 11:50 |
MTDiscord |
<wsor4035> @paradust |
| 11:52 |
|
Desour joined #minetest-dev |
| 12:26 |
MTDiscord |
<paradust> 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 |
<paradust> 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. |
| 12:43 |
|
grorp1 joined #minetest-dev |
| 13:32 |
|
jonadab joined #minetest-dev |
| 13:38 |
|
fluxionary joined #minetest-dev |
| 13:41 |
|
fluxionary_ joined #minetest-dev |
| 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 |
<paradust> are you sure that patch works? I don't see why it would |
| 14:52 |
MTDiscord |
<paradust> in my testing, just accessing "this" inside ~LogStream caused a crash |
| 14:53 |
MTDiscord |
<paradust> also, for some reason, it almost never crashes unless i'm running it under gdb |
| 14:54 |
MTDiscord |
<paradust> 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] |
<giov4> hey everyone, is there a particular way of using sound groups? 'cause, according to the docs, having three sound files named "<same-name>.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 |
<warr1024> 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 "<same-name>" part without any extensions. |
| 15:11 |
[MTMatrix] |
<giov4> oh ok, I thought it was the right room since the room description says "modding discussion is on-topic" |
| 15:19 |
MTDiscord |
<warr1024> 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. |
| 16:43 |
|
fluxionary_ joined #minetest-dev |
| 17:17 |
|
fluxionary joined #minetest-dev |
| 18:24 |
|
Wuzzy joined #minetest-dev |
| 18:25 |
|
Pong490 joined #minetest-dev |
| 18:29 |
|
grorp joined #minetest-dev |
| 18:42 |
|
appguru joined #minetest-dev |
| 19:19 |
|
appguru joined #minetest-dev |
| 19:21 |
MTDiscord |
<paradust> 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 |
<paradust> 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:32 |
|
calcul0n_ joined #minetest-dev |
| 20:39 |
MTDiscord |
<paradust> After making a fix, it crashes for an entirely different reason. \o/ |
| 20:41 |
MTDiscord |
<paradust> uninit_common is registered via atexit() near the beginning of main. This calls httpfetch_cleanup which uses verbosestream. |
| 20:42 |
MTDiscord |
<paradust> But the destructor for verbosestream is called before atexit calls this |
| 20:46 |
MTDiscord |
<paradust> 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 |
<paradust> but when I moved the entire LogStream into an allocation, and destroy it for real, now it crashes |
| 20:50 |
MTDiscord |
<paradust> this should really be using RAII anyway instead of atexit |
| 22:00 |
|
appguru joined #minetest-dev |
| 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 |
<paradust> even with my fix to the log stuff, there are additional crashes due to tls weirdness |
| 22:43 |
MTDiscord |
<paradust> this one crashes, much more rarely: https://github.com/minetest/minetest/blob/master/src/client/tile.cpp#L515 |
| 22:43 |
MTDiscord |
<paradust> in the destructor |
| 22:56 |
MTDiscord |
<paradust> https://0x0.st/Hgfe.txt |
| 23:26 |
sfan5 |
unfortunate |
| 23:32 |
|
panwolfram joined #minetest-dev |
| 23:38 |
MTDiscord |
<paradust> Is the official windows release compiled using mingw or msvc? |
| 23:39 |
MTDiscord |
<paradust> Apparently Clang can be used as an alternative compiler inside MSVC. I wonder if that would be much better |
