Minetest logo

IRC log for #minetest-dev, 2019-03-07

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:36 turtleman joined #minetest-dev
00:42 benrob0329 joined #minetest-dev
00:49 ANAND joined #minetest-dev
00:54 Cornelia joined #minetest-dev
01:23 Wuzzy What do rudp_rtt, rudp_jitter and packets_lost in the profiler graph mean?
01:45 T4im joined #minetest-dev
01:47 paramat joined #minetest-dev
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:20 Miner_48er joined #minetest-dev
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:52 benrob0329 joined #minetest-dev
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:04 ssieb joined #minetest-dev
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
03:44 diemartin joined #minetest-dev
04:11 kaeza joined #minetest-dev
04:17 asl97 joined #minetest-dev
04:53 Wuzzy joined #minetest-dev
04:53 bobby joined #minetest-dev
05:00 diemartin joined #minetest-dev
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.
05:45 kaeza joined #minetest-dev
06:17 ssieb joined #minetest-dev
06:22 diemartin joined #minetest-dev
06:26 paramat joined #minetest-dev
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:02 kaeza joined #minetest-dev
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:42 diemartin joined #minetest-dev
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
08:00 asl97 left #minetest-dev
08:49 ensonic joined #minetest-dev
09:41 proller joined #minetest-dev
10:49 proller joined #minetest-dev
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:04 troller joined #minetest-dev
11:08 Fixer joined #minetest-dev
11:15 Beton joined #minetest-dev
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
11:27 proller joined #minetest-dev
12:01 IcyDiamond left #minetest-dev
12:04 bodqhrohro joined #minetest-dev
12:35 kaeptmblaubaer joined #minetest-dev
12:36 kaeptmblaubaer joined #minetest-dev
13:03 YuGiOhJCJ joined #minetest-dev
13:07 kaeptmblaubaer joined #minetest-dev
13:17 p_gimeno joined #minetest-dev
13:17 kaeptmblaubaer joined #minetest-dev
13:40 kaeptmblaubaer joined #minetest-dev
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:09 kaeptmblaubaer joined #minetest-dev
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:16 argyle77 joined #minetest-dev
15:25 twoelk joined #minetest-dev
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:14 Icedream joined #minetest-dev
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
16:41 kaeza joined #minetest-dev
17:24 ensonic joined #minetest-dev
18:09 twoelk left #minetest-dev
18:15 Icedream joined #minetest-dev
18:22 proller joined #minetest-dev
19:24 troller joined #minetest-dev
19:27 argyle77 joined #minetest-dev
19:57 fwhcat joined #minetest-dev
20:14 kaeza joined #minetest-dev
21:43 proller joined #minetest-dev
21:59 ShadMOrdre joined #minetest-dev
22:05 ShadMOrdre left #minetest-dev
22:41 GreenDimond joined #minetest-dev
23:14 p_gimeno does MAP_LOCK_REQUIRED do anything? or is it just like a comment? it's defined as empty
23:24 ircSparky joined #minetest-dev
23:55 Taoki joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext