Time  Nick        Message
01:23 Wuzzy       What do rudp_rtt, rudp_jitter and packets_lost in the profiler graph mean?
02:08 paramat     #8220 is not at all urgent, the docs already warn not to use emin-emax, and doing so is almost never needed anyway. this doesn't need attention for 5.0.1, there are hundreds of more important issues than this
02:08 ShadowBot   https://github.com/minetest/minetest/issues/8220 -- Parameter checking needed for LVM 'calc_lighting' to not be set to emin/emax (crash was caused by a mod code error)
02:09 paramat     we should spend precious dev time elsewhere
02:11 VanessaE    oh ffs
02:22 VanessaE    paramat: warning not to do stupid stuff lest the engine crash and burn not only does NOT help fix a mod that *already* does stupid stuff but isn't identified as the cause, it also shows a lack of care.  the engine should NEVER segfault when handed bad mod code.
02:23 VanessaE    it should be like the kernel - it should never under any circumstances oops/panic/bug/etc when given broken userland code.
02:24 paramat     i agree
02:26 paramat     it's lack of time, not lack of care, there are many other places needing parameter checking too
02:26 p_gimeno    that's just impossible; granting a mod insecure privileges under luajit makes it able to crash the server in case of error
02:26 VanessaE    p_gimeno: but does it just shit itself, or does it throw a proper lua backtrace?
02:29 paramat     for 5.0.1, just like 5.0.0 we can only attend to extremely urgent bugs, this is far from being one
02:29 VanessaE    wat
02:29 VanessaE    5.0.0 isn't even out for a week and you're already declaring 5.0.1-must-be-out-asap ?
02:30 paramat     i've even asigned myself to this, will attend once release is sorted out
02:30 paramat     *assigned
02:31 paramat     we have an urgent inventory bug that needs quickly fixing, so 5.0.1 will be out in a few days, read up on what's been happening
02:32 p_gimeno    VanessaE: ffi can cause a segfault, not just a backtrace
02:32 GreenDimond https://github.com/minetest/minetest/milestone/14 :) much to do ouch
02:33 VanessaE    p_gimeno: ffi is a different animal though.
02:34 VanessaE    paramat: I know about the inventory bug.
02:34 p_gimeno    VanessaE: *shrug* the point stands, misuse it and you get a segfault
02:34 VanessaE    p_gimeno: the point is, I've got a segfault happening that I cannot fix until the engine tells me where the crash originated.
02:35 VanessaE    I don't give two shits that it crashes.
02:35 VanessaE    I just care that I don't get a lua backtrace.
02:35 VanessaE    and this isn't the first time this sort of thing has happened (though to be fair, it's been a good while)_
02:44 p_gimeno    segfaults don't generate backtraces, they are critical errors
02:44 VanessaE    exactly my point..
02:45 p_gimeno    IIRC paramat already told you where the crash originated
02:45 VanessaE    no..
02:46 VanessaE    he said one api call that'll crash given bad parameters.
02:46 VanessaE    that doesn't help me find the *mod* with the bad call (I've already looked for it).
02:48 p_gimeno    https://github.com/minetest/minetest/issues/8220#issuecomment-462465670
02:50 VanessaE    I repeat - that just tells me an API call that's broken.
02:50 VanessaE    it doesn't help me find the *mod* that needs fixed.
02:50 VanessaE    because I've already corrected the only references to that call that I could find.
02:51 VanessaE    it doesn't do me any favors that I'm trying to fix someone *else's* mod(s), either
02:53 p_gimeno    so, let me see if I get this right. You've looked for all instances of calc_lighting, you've fixed the parameters, and you are still getting a crash with the same gdb backtrace. Is that right?
02:53 VanessaE    yep.
02:54 VanessaE    so some mod may be redefining it, or there's another call that takes the same code path and ends in a segfault.
02:56 VanessaE    either way I had to give up fixing it.  nothing I can do until I get a proper lua backtrace
02:59 paramat     ah
03:04 paramat     exact same backtrace? 'Mapgen::propagateSunlight' and 'Mapgen::calcLighting' as #0, #1?
03:04 ShadowBot   paramat: Error: Delimiter not found in "HTTP Error 404: Not Found"
03:04 ShadowBot   https://github.com/minetest/minetest/issues/1 -- GlowStone code by anonymousAwesome
03:06 p_gimeno    and # 2 which tells which lua function caused it
03:09 VanessaE    paramat: I believe so, but it's been a while since I last saw the crash.
03:09 VanessaE    (being likely mapgen-related, on a server with a very old map)
03:17 * VanessaE  wanders off
03:19 paramat     hm ok, unless you know for sure we don't know it is the same bug. there are some other bugs that result in a backtrace involving light calculations, you might be remenbering those
03:19 paramat     next time it happens, please post the backtrace in an issue
05:26 asl97       Don't mind me, I was reading through my email and I saw a mail about Mapgen OOM, Is Mapgen OOM still an issue though? I am just going to point to a solution which I proposed some time ago (which hopefully is still relevant).
05:26 asl97       I would personally recommend a new api that just directly passing table between mod (with an config to disable checking the data between mods for performance) instead of converting between c++ and lua for every mod using the api.
05:26 asl97       Although since 5.0.0 is out, I guess it's too late to consider major changes to how mod-mapgen interaction works.
05:26 asl97       There is still the use same table internally option to reduce memory usage but that just a dumb band-aid.
05:26 asl97       #6617 implementation ignore the passed table, which break mods that expect the passed table to get modified.
05:26 asl97       To prevent breakage, one can use the passed table but that wouldn't reduce the memory usage unless mods get changed to not use their own table.
05:26 ShadowBot   https://github.com/minetest/minetest/issues/6617 -- Reuse vmip/noise/param2 table whenever possible by asl97
05:29 sofar       asl97: our builds now by default have LuaJIT with gc64, which will hopefully help a lot
05:32 asl97       sofar: that only helps with the OOM but I suppose that was the main issue.
05:33 sofar       the only real solution is for mods to queue and throttle work
05:38 asl97       isn't that just moving the problem around?  the minetest mapgen api does a lot to prevent mods from clashing but that has overhead.
06:31 paramat     mapgen OOM is a Lua memory problem not an engine problem, 6617 isn't a 'solution' although it may still be good. as far as i know only windows builds have gc64
06:32 asl97       paramat: like i said, it a dumb band-aid
06:41 nerzhul     merging #8331
06:41 ShadowBot   https://github.com/minetest/minetest/issues/8331 -- Fix detach inventory serialisation by rubenwardy
06:42 asl97       while it might be a lua memory problem but it's also an api design problem, if you go recommending each mod uses their own buffer, what else can you expect if not OOM?
06:43 nerzhul     i pushed the two network fixes to stable-5
06:49 paramat     6617 was closed because you are proposing a new idea, is there an issue for your new proposal? if not, please open one otherwise your suggestion will get no attention
06:50 asl97       paramat: I am pretty sure my idea was rejected due to breaking the api way back then
06:58 asl97       so unless that has changed and there is an intent on rewritting the api, I don't see how my suggestion gonna get anywhere even if I did create an issue, not to mention I don't open an issue that I don't intent on following up on.
07:03 paramat     nuuu, 6617 was problematic because it was not optional and could break mods, but your new idea may be fine
07:04 paramat     what do you mean by 'following up on'? writing a PR?
07:05 paramat     we can't break mods though and the old way of doing things still needs to be possible
07:05 asl97       keeping up to date, answering question, clarifying stuff, those kind of thing
07:06 nerzhul     #6617
07:06 ShadowBot   https://github.com/minetest/minetest/issues/6617 -- Reuse vmip/noise/param2 table whenever possible by asl97
07:06 asl97       also, having two api that does the same thing is kind of stupid and would only increase memory usage, I want no part of that
07:09 paramat     proposing a good idea is valuable even if you disappear afterwards. we can't judge your new API idea unless you describe it in an issue
07:11 paramat     6617 gives the impression that your new suggestion is somewhat different to 6617, so we are unable to consider the new suggestion
07:12 paramat     besides, closed issues are ignored
07:13 paramat     (closed PRs i mean)
07:13 asl97       It is different and I don't really want to research all that stuff again, I am mostly here due to an email I gotten
07:15 paramat     ok, but chat in this channel is likely to be forgotten, so an issue is needed too, up to you
07:15 asl97       beside, iirc, the idea was already descript in https://github.com/minetest/minetest/issues/2988#issuecomment-342701232
07:16 paramat     ok, but a post in another thread will also not get any attention
07:16 nerzhul     merging #8319
07:16 ShadowBot   https://github.com/minetest/minetest/issues/8319 -- Update a few dependency versions for buildbot by sfan5
07:19 nerzhul     emrging trivial #8193
07:19 ShadowBot   https://github.com/minetest/minetest/issues/8193 -- Optimize interaction distance checker by osjc
07:20 nerzhul     and #8098
07:20 ShadowBot   https://github.com/minetest/minetest/issues/8098 -- Optimize string handling in path search by osjc
07:21 paramat     note that FFI is also being proposed for similar reasons
07:22 asl97       if someone thought it was important enough, they would have opened an issue about it.  I would be more interested in a rewrite if minetest ever get one.
07:23 nerzhul     merging #7396
07:23 ShadowBot   https://github.com/minetest/minetest/issues/7396 -- World config: Make depends easier to read by HybridDog
07:25 paramat     should we be merging low priority and possibly risky PRs just before a rerelease of 5.0? for example 8098
07:25 nerzhul     i'm on master, not stable-5
07:25 paramat     i would have thought now is not the time to merge as much as possible
07:25 nerzhul     i merge already approved PRs and i re-read them each time
07:25 nerzhul     i see you are working on mapgens problem
07:26 nerzhul     branches are here for a such thing
07:27 paramat     "if someone thought it was important enough, they would have opened an issue about it" perhaps that person is you?
07:27 nerzhul     and i don't merge as much as possible, i merge the safest prs
07:27 nerzhul     see the PR list you will see i didn't merged some page 1 or page 2 pr
07:27 paramat     oh, we're rereleasing stable-5? ok
07:27 nerzhul     stable-5 is for bugfixes
07:28 nerzhul     5.0.1 will come from here
07:28 nerzhul     5.1.0 is on master
07:28 paramat     ok sorry
07:29 asl97       paramat: Honestly, I stop caring about trying to get changes to minetest itself and just work around issues
07:30 paramat     a rewrite will be a MT fork
07:31 nerzhul     merging #7011
07:31 ShadowBot   https://github.com/minetest/minetest/issues/7011 -- Abort when trying to set a not registered node by HybridDog
07:31 asl97       that's like saying 1.13 forge is a forge fork >.>
07:34 paramat     if you're negative and self-defeating the lack of change is your own fault. your API suggestion won't happen because you're too negative to open an issue, not our fault
07:35 paramat     no more offtopic please
07:47 asl97       I ain't saying it's your fault. In any case I already gotten what I was looking for and more, I guess I leave it at that.
07:47 paramat     if you don't care and can't make any effort don't waste our time coming here to propose something
07:48 asl97       wasn't proposing, was simply looking for some info for which I could send as a reply
07:52 asl97       and then I kind of rant like I usually do and posted that big first message,  sorry for that I suppose
10:58 sfan5       <paramat> should we be merging low priority and possibly risky PRs just before a rerelease of 5.0? for example 8098
10:59 sfan5       I think 5.0.1 would get prepared on a separate branch based on stable-5 anyway, since we've already "contaminated" master with unrelated commits
11:23 nerzhul     master is for 5.1.0, also it's why we has changed our version scheme we can now easily prepare patches on stable branches
13:53 sfan5       why are there additional commits on the stable-5 branch?
13:54 rubenwardy  can we revoke nerzhul's push access :D
13:54 rubenwardy  also, it should be 5.0.1-dev at the very least
13:54 sfan5       nerzhul: WHERE IS THE FUCKING APPROVAL
13:54 sfan5       stop doing stupid shit
13:55 sfan5       yes we want those commits on stable-5
13:55 sfan5       but not now
13:55 sfan5       keep them somewhere else
13:55 sfan5       rubenwardy: it is -- *** Will build version 5.0.1-dev ***
13:55 rubenwardy  ah, it's fixed by another commit : https://github.com/minetest/minetest/commit/1653a724e6237b69f37aa4a3e5d0ff97ed3389ab
13:56 sfan5       stable-5 is not work work in progress stuff
13:56 sfan5       stable-5 contains the latest version
13:56 sfan5       5.0.1-dev is not the latest released version
13:57 sfan5       there, fixed
14:40 p_gimeno    is there some kind of critical section object I should use when I create a patch that needs thread locking? or would I just use std::mutex?
14:41 p_gimeno    I see MutexAutoLock used at some points
14:41 p_gimeno    I'm not sure what the Auto part means
14:42 rubenwardy  RAII?
14:45 p_gimeno    so, should I be using that?
14:45 p_gimeno    I haven't used that kind of locks, I'm very classic :)
14:53 sfan5       yes std::mutex
14:56 p_gimeno    thanks
15:49 nerzhul     sfan5 it's backport commits on approved cmmits by yourselves guys
15:49 nerzhul     why are your doing a backport branch where there is a stable branch for that ?
15:50 nerzhul     p_gimeno: you can use std::lock_guard directly
15:50 nerzhul     RAII is the safer way
15:53 p_gimeno    thanks
15:53 nerzhul     but in some areas it cannot work, but generally it's the safer way, because RAII permits to ensure mutex is unlock in any return part or expcetion path :)
16:19 sfan5       nerzhul: yes, approval for pushing to master not to stable-5
16:19 sfan5       stable-5 should only ever contain a stable release, no work in progress commits
16:19 sfan5       at least that's my opinion and I think others agree with that
16:20 sfan5       i've moved your commits to "nrz-stable-5" btw, so they don't get lost
16:21 nerzhul     i pushed my own commits ?
16:21 sfan5       the commits you pushed, not literally your commits
16:21 nerzhul     i don''t see that branch, i only see stable-5 and backport-5, did you pushed it ?
16:21 sfan5       well it was there ealier, not sure who removed it
16:22 nerzhul     okay :)
16:22 nerzhul     sorry for that
16:22 nerzhul     just wanted to prepare backport :)
16:22 sfan5       by the way, I don't think the "continue with 5.1.0-dev" commit should be on the backport branch
16:22 rubenwardy  I renamed it to be consistent with 0.4
16:22 rubenwardy  and I agree with that ^
16:23 rubenwardy  doesn't matter too much, it's just a git mistake
16:23 nerzhul     sfan5 right
16:24 sfan5       any opinion on including these additional fixed in 5.0.1? >> https://github.com/minetest/minetest/milestone/14
16:24 nerzhul     8258 ok but we should merge on master before
16:25 rubenwardy  I think that 5.0.1 should be soon, and only include what would have been blockers or near blockers
16:25 nerzhul     crashes are the most important part
16:25 rubenwardy  I'd like 5.0.0 to go from Android beta to main asap
16:25 rubenwardy  yeah
16:25 nerzhul     we can do 5.0.2 later
16:25 rubenwardy  exactly
16:25 sfan5       rubenwardy: would that include the noise.cpp bugfix?
16:25 nerzhul     rubenwardy when the crash is fixed i push to beta + production 1 week after
16:25 p_gimeno    8328 is WIP and it may be the result of a misdiagnosis, I'm investigating that
16:25 nerzhul     i cannot let client crash like this on servers it will be bad
16:26 sfan5       because I'd prefer such a thing to be in 5.0.1 rather than telling affected users to go to 5.1.0-dev (or even releasing a 5.0.2)
16:26 rubenwardy  what's the crash?
16:26 rubenwardy  ohh, the inventory thing
16:26 nerzhul     yes
16:26 p_gimeno    https://github.com/minetest/minetest/issues/8300#issuecomment-470577952
16:27 sfan5       p_gimeno: have you found out if mapgen threads share their noise?
16:27 p_gimeno    I think they shouldn't be, that's what I'm investigating
16:28 p_gimeno    each has its own noise object
23:14 p_gimeno    does MAP_LOCK_REQUIRED do anything? or is it just like a comment? it's defined as empty