| 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 |
