| Time |
Nick |
Message |
| 00:15 |
|
EvergreenTree joined #minetest-dev |
| 00:45 |
|
jojoa1997 joined #minetest-dev |
| 01:01 |
|
Gronx joined #minetest-dev |
| 01:25 |
|
RealBadAngel joined #minetest-dev |
| 01:31 |
|
OldCoder joined #minetest-dev |
| 01:33 |
|
kahrl joined #minetest-dev |
| 01:53 |
|
bas0801 joined #minetest-dev |
| 02:15 |
|
bas080 joined #minetest-dev |
| 02:45 |
|
zork__ joined #minetest-dev |
| 04:17 |
|
bas080 joined #minetest-dev |
| 06:04 |
|
ImQ009 joined #minetest-dev |
| 06:59 |
|
darkrose joined #minetest-dev |
| 08:39 |
celeron55 |
19:12:44 <+sapier> is there any major issue that would be fixed by starting from scratch I missed by now |
| 08:40 |
celeron55 |
i said i would like to do a focused effort with someone on researching the subject, but then everyone started just shouting around miscellaneous things like usual |
| 09:04 |
|
OldCoder joined #minetest-dev |
| 09:23 |
|
khonkhortisan joined #minetest-dev |
| 10:05 |
|
proller joined #minetest-dev |
| 10:51 |
proller |
celeron55, one more shoot around: universe sized game, top level - lot of gravity points (planets, stars), every point can contain world like current |
| 10:52 |
proller |
with rotating planet sky can be real, with reachable (via teleport) start and planets |
| 10:54 |
celeron55 |
don't say those to me; nobody gains anything from it |
| 10:54 |
celeron55 |
except you gain a little bit of hate from me |
| 10:55 |
celeron55 |
it's and odd thing to desire i must say |
| 10:55 |
celeron55 |
an* |
| 12:27 |
|
ImQ009 joined #minetest-dev |
| 13:12 |
|
EmmetCooper joined #minetest-dev |
| 13:12 |
|
EmmetCooper left #minetest-dev |
| 13:17 |
|
EvergreenTree joined #minetest-dev |
| 13:20 |
|
hmmmm joined #minetest-dev |
| 13:34 |
|
Taoki joined #minetest-dev |
| 13:45 |
|
proller joined #minetest-dev |
| 13:46 |
proller |
https://github.com/minetest/minetest/pull/999 jack pot! |
| 13:47 |
celeron55 |
someone has to make sure 1000 is the best pull request ever |
| 13:49 |
celeron55 |
maybe i should aim for fixing the object duplication more tonight and making pull #1000 out of it |
| 13:49 |
celeron55 |
(i'm pretty sure someone accidentally makes #1000 out of something random before that) |
| 13:50 |
Kray |
i'm gonna make lörs lärä request |
| 13:50 |
Kray |
and you can't prevent it |
| 13:51 |
celeron55 |
well that's better than something else i guess |
| 13:52 |
proller |
wtf with guiFormSpecMenu.cpp ? why conflict? http://paste.org.ru/?z4joi2 |
| 13:54 |
proller |
looks like rebase in master |
| 13:58 |
celeron55 |
note the spaces before '+'s |
| 13:58 |
celeron55 |
they are diffs stored in the actual file in the repo |
| 13:58 |
proller |
but i not touched this file |
| 13:58 |
proller |
strange |
| 14:00 |
sfan5 |
can someone please fix this: src/util/numeric.cpp:146: error: integer constant is too large for ‘long’ type |
| 14:02 |
celeron55 |
http://stackoverflow.com/questions/11691121/warning-integer-constant-too-large-for-long-type-but-it-is-a-uint64-t |
| 14:02 |
celeron55 |
try it yourself |
| 14:12 |
sfan5 |
fix incoming in 5 mins |
| 14:13 |
celeron55 |
so that's the 1000th pull request? :P |
| 14:16 |
sfan5 |
no, I'll push directly |
| 14:17 |
sfan5 |
1000 deserves something better :P |
| 14:21 |
|
NakedFury joined #minetest-dev |
| 14:40 |
|
zat joined #minetest-dev |
| 14:49 |
|
Zeitgeist_ joined #minetest-dev |
| 14:58 |
|
iqualfragile joined #minetest-dev |
| 15:24 |
|
RealBadAngel joined #minetest-dev |
| 15:29 |
ShadowNinja |
zat: Have you been able to add multiple lines to /rollback_check output yet? |
| 15:31 |
zat |
I haven’t had time |
| 15:31 |
zat |
I am really busy with family stuff sorry |
| 15:32 |
zat |
However can the new rollback be included as is in the next minor version? |
| 15:32 |
proller |
hahahahaha |
| 15:34 |
ShadowNinja |
zat: I would like to get it in 0.4.8, but it has to be ready soon. I will see if I can fix rollback_check myself. |
| 15:46 |
|
Ritchie_ joined #minetest-dev |
| 15:50 |
zat |
I would rather call it a feature improvement. Since now it works as it claims to. |
| 15:59 |
|
PilzAdam joined #minetest-dev |
| 16:00 |
|
Jordach joined #minetest-dev |
| 16:10 |
|
EvergreenTree joined #minetest-dev |
| 16:22 |
ShadowNinja |
Yes, but either way... |
| 16:24 |
|
Calinou joined #minetest-dev |
| 16:28 |
PilzAdam |
I dont think that 997 is a "blocker" |
| 16:32 |
PilzAdam |
its already in a stable release and its not that important to block a release |
| 16:33 |
celeron55 |
activeobject bug counter: 1 |
| 16:40 |
|
OldCoder joined #minetest-dev |
| 16:41 |
thexyz |
and well the patch is already here so instead of arguing whether it's a blocker or not why not merge it? |
| 16:41 |
celeron55 |
stumbled upon sapier's fix which only makes things worse in this regard |
| 16:43 |
celeron55 |
(activeobject bug counter: 2) |
| 16:48 |
|
sapier joined #minetest-dev |
| 16:53 |
|
zat joined #minetest-dev |
| 16:53 |
sapier |
celeron55 what fix are you talking about? |
| 16:57 |
|
zat joined #minetest-dev |
| 17:00 |
ShadowNinja |
zat: You should use a time_t instead of a int. A int can be 32 or even 16 bits long, which isn't enough to store time. |
| 17:01 |
sapier |
you're right shadow time_t is correct but I guess there's no 16bit os available to run minetest at |
| 17:04 |
sapier |
PilzAdam imho any known (not exremely rare) crash is a blocker no matter if it was there before or not |
| 17:06 |
ShadowNinja |
sapier: Even 32-bit will be too small soon. (I forget when) |
| 17:07 |
ShadowNinja |
And the timestamp in the DB should be a "TIMESTAMP", not a "INTEGER". |
| 17:07 |
sapier |
unix time has epochs ;-) |
| 17:07 |
sapier |
we just start a new one soon |
| 17:14 |
celeron55 |
what changes related to this bug have there been? |
| 17:14 |
zat |
ShadowNinja: that wont make difference unless I want to use certain functions for date/time. |
| 17:14 |
zat |
still, they should work |
| 17:14 |
celeron55 |
i have some very strange behavior and would really like to make sure it's not caused by some half-thought quickfix |
| 17:15 |
sapier |
I remember only one bugfix directly related to entities that one where entities got disabled by client while server still thought they were active thus they never got resent to client |
| 17:15 |
celeron55 |
where's that? |
| 17:15 |
celeron55 |
sounds relevant |
| 17:16 |
sapier |
puuhh was marged some months ago |
| 17:16 |
sapier |
merged |
| 17:16 |
celeron55 |
yes, what is the commit message or changed line or something? |
| 17:16 |
celeron55 |
or who did it |
| 17:16 |
sapier |
I have a look for it |
| 17:20 |
sapier |
https://github.com/sapier/minetest/commit/0ac74f36e2599116897f3e27ca973162a8dbbe3f |
| 17:21 |
celeron55 |
wtf |
| 17:21 |
celeron55 |
i have a local modification here that basically rolls back that change |
| 17:22 |
sapier |
then you'll loose entities on client again |
| 17:22 |
celeron55 |
that "fix" isn't a fix at all; it somehow avoids the client losing the object by duplicating the object |
| 17:22 |
sapier |
actually the client doesn't loose the object |
| 17:22 |
celeron55 |
so that the one that the client lost stays on the server and the server creates a duplicate that it sends to the client |
| 17:22 |
sapier |
the object is unloaded on purpose |
| 17:23 |
celeron55 |
that patch is the main reason for object duplication |
| 17:23 |
sapier |
ok then we need to find a way to make server send objects to clients again |
| 17:23 |
celeron55 |
well OBVIOUSLY we do |
| 17:24 |
sapier |
I guess I didn't see the duplication there but what I know is client deactivates the object while server doesn't |
| 17:24 |
sapier |
and server only sends objects on activation thus the object never is sent again |
| 17:25 |
celeron55 |
the server deactivates the object just fine |
| 17:25 |
sapier |
it's quite simple to trigger the bug I tried to fix there |
| 17:25 |
celeron55 |
the issue is that it somehow doesn't re-activate it afterwards when it should |
| 17:25 |
sapier |
put a object somewhere |
| 17:25 |
celeron55 |
i can reproduce this completely predictably |
| 17:25 |
celeron55 |
that's why i am so directly blaming you |
| 17:26 |
celeron55 |
8) |
| 17:26 |
sapier |
I don't have a problem yet if this one isn't a propper solution for the original problem we still need a solution for that one ;-) |
| 17:27 |
celeron55 |
well i would be far in the making of it by now if i wouldn't have had to hunt this down first |
| 17:27 |
sapier |
while missing entities are way better as of servers point of view ... for gameplay missing is as bad as duplication |
| 17:28 |
sapier |
don't blame me I told multiple times that this fix might be related to duplication ... a fix for loss is always suspicious for duplication ;-) |
| 17:28 |
ShadowNinja |
zat: It will work until time needs more than 32 bits. You also should align things with spaces, as developers set different tab widths. (I use 8, it looks like you use 4) |
| 17:28 |
PilzAdam |
sapier, you do realise that the duplications are more than 1000 per object, that causes massive FPS dropdowns (from 60 to 1 or 2) |
| 17:28 |
PilzAdam |
and you think that is as bad as missing objects for the gameplay? |
| 17:29 |
sapier |
it is |
| 17:29 |
sapier |
in fact you almost everytime loose most of entities until you restart client |
| 17:29 |
celeron55 |
i found the original bug now... and it's really trivial |
| 17:30 |
celeron55 |
(...if one knows how this thing works) |
| 17:30 |
sapier |
:-) obviously you're the only one who really does numerous ppl have been looking for the entity loss issue before me |
| 17:31 |
|
djdduty joined #minetest-dev |
| 17:31 |
sapier |
need to restart my router ... firmware update |
| 17:33 |
sapier |
btw celeron55 you did look at that commit prior merge too ;-) |
| 17:33 |
zat |
ShadowNinja: you really think my table structure will remain unchanged until 2038? |
| 17:34 |
zat |
and that compilers / storage engines won’t work that around even if so? |
| 17:34 |
zat |
:PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP |
| 17:34 |
PilzAdam |
zat, whats wrong with changing it to work until the universe collapses? |
| 17:35 |
|
sapier1 joined #minetest-dev |
| 17:35 |
sapier1 |
btw celeron55 you did look at that commit prior merge too ;-) |
| 17:35 |
zat |
PilzAdam: having searches on integer columns perform much better than in numeric (actually varying char) columns. |
| 17:36 |
celeron55 |
sapier: it's impossible to know if a bugfix is correct without understanding the bug |
| 17:36 |
celeron55 |
nobody understood that bug at the time |
| 17:36 |
sapier1 |
of course obviously I missunderstood bug too |
| 17:38 |
celeron55 |
understanding this bug is actually quite easy; it's related to the two different forms of static objects; but a correct fix requires more than little of thought |
| 17:38 |
sapier |
It's always easy if you know how things are supposed to work ;-) |
| 17:39 |
sapier |
yet I'm glad if this is fixed correct finaly |
| 17:39 |
ShadowNinja |
zat: And at least one newline between functions please. |
| 17:39 |
sapier |
my appologies to everyone suffering from incorrect fix |
| 17:40 |
zat |
ShadowNinja: stop forcing me to code the way you personally like |
| 17:41 |
zat |
once again and I am done contributing to minetest. |
| 17:42 |
sapier |
zat http://dev.minetest.net/Code_style_guidelines is the only thing you are forced to do ... everything else is things you to to make coredevs more pleasant to merge the pulls ;-) |
| 17:43 |
ShadowNinja |
^ I beleive that requires two newlines, but that isn't really folowed in the code, although one is. |
| 17:44 |
sapier |
lol "Contrary to what some people may believe, NULL is a part of the official C++ standard. " someone wanted to have last word ... right ;-) NULL is defined in standard as "implementation specific" ... so at least that sentence is correct :-) |
| 17:44 |
zat |
even a single newline between functions makes them look horrible when folded in vim. |
| 17:45 |
sapier |
don't use vim ;-) imho between functions there should even bee a /***/ line ;-) |
| 17:45 |
zat |
eh |
| 17:45 |
sapier |
at least in cpp files ... but that's my personal preference too |
| 17:46 |
ShadowNinja |
zat: Folded? I use vim and they look better with a newline. |
| 17:46 |
sapier |
vim .... surrounded by masochists :-) |
| 17:47 |
zat |
ShadowNinja: that is your humble opinion. |
| 17:47 |
zat |
sapier: ???, I just cannot stop using vim now. |
| 17:47 |
sapier |
I know it's difficult to switch habits |
| 17:47 |
zat |
Give me another IDE and code ends up full of :w, :x, :q and closing the document accidentally every one minute. |
| 17:49 |
celeron55 |
i use vim |
| 17:49 |
sapier |
everyone should use it's editor of preference yet code needs to be as easy to read as possible for all editors |
| 17:49 |
celeron55 |
but i don't use folding of functions in vim, and if the folding of functions looks bad in some editor, it's the editor's, not the codes fault |
| 17:49 |
sapier |
I gues snow I know why debug is -O1 :-) |
| 17:50 |
proller |
astyle --style=attach --indent=tab --keep-one-line-blocks --keep-one-line-statements --indent-classes --pad-oper *.cpp *.h |
| 17:50 |
sapier |
celeron if that would be true we wouldn't have to stick to 80 chars per line |
| 17:50 |
proller |
^ minetest-friendly |
| 17:50 |
zat |
celeron55: I cannot blame the editor for not looking the way that I personally like. |
| 17:51 |
celeron55 |
proller: --indent-classes is wrong |
| 17:51 |
zat |
Or at least cannot say, objectively, it is not a good editor. |
| 17:52 |
celeron55 |
it's sad that vim uses it's own obscure scripting language but whatever, can't help that |
| 17:53 |
sapier |
celeron is the magic all entity problems fixing pull request supposed to be #1k |
| 17:53 |
|
rubenwardy joined #minetest-dev |
| 17:53 |
celeron55 |
i hope nobody creates a pull request or issue before i get this properly tested |
| 17:54 |
celeron55 |
maybe i should already create it and update it along the way |
| 17:54 |
sapier |
I suggest creating it and add force push the final version ;-) |
| 17:54 |
sapier |
:-) same idea |
| 17:56 |
celeron55 |
https://github.com/minetest/minetest/pull/1000 |
| 17:56 |
celeron55 |
8) |
| 17:56 |
sapier |
"once and for all" brave claim :) |
| 17:57 |
rubenwardy |
Woooo hoooo! |
| 17:58 |
celeron55 |
if that happens to compile, feel free to test; but it's not intended to work yet |
| 17:58 |
celeron55 |
recompiling after switching branch on my laptop takes so many minutes i guess i'll go eat now |
| 17:59 |
kaeza |
yay pull #1000 :D |
| 17:59 |
rubenwardy |
1000 :O |
| 18:00 |
sapier |
lets open some bottles of champagne ;-) |
| 18:00 |
ShadowNinja |
sapier: So, why are spaces in list names invalud? |
| 18:01 |
sapier |
because it crashes serialization :-) ask PilzAdam he said this is invalid anyway |
| 18:01 |
sapier |
my patch just prevents ppl from creating those lists |
| 18:01 |
ShadowNinja |
Ah, just saw his comment. Perhaps serialization should be fixed then. |
| 18:02 |
sapier |
I don't see any use in listnames with " " ... they're identifyers not descriptions |
| 18:02 |
sapier |
yes technicaly " " is a character as any other :-) |
| 18:03 |
PilzAdam |
ShadowNinja, the format is "List main 32" so "List <name> <size>" |
| 18:03 |
ShadowNinja |
Yes, but why not allow "This is some list with\nfancy characters. :-)" |
| 18:03 |
|
Jordach joined #minetest-dev |
| 18:04 |
ShadowNinja |
"List with\ spaces 123" |
| 18:04 |
kaeza |
don't see why would anyone use spaces in list, as sapier said |
| 18:04 |
kaeza |
listnames* |
| 18:04 |
sapier |
why increase complexity of code for no sane reason? |
| 18:04 |
ShadowNinja |
Ok, it can always be added later... |
| 18:05 |
sapier |
yes but imho only if someone really finds a sane reason to do so ;-) |
| 18:05 |
PilzAdam |
ShadowNinja, it can not be added without breaking the serialization format, so that will not happen |
| 18:06 |
sapier |
PilzAdam did you read my explanation in pull request? |
| 18:07 |
PilzAdam |
yes |
| 18:07 |
sapier |
any open questions left? |
| 18:09 |
sapier |
I remember someone fixed the formspec chat overlay issue some weeks ago better then my version does anyone remember who did this? |
| 18:10 |
thexyz |
proller: #999 how about looping through the list of players and checking if the player we're sending message to is the one who died? |
| 18:11 |
sapier |
I know we can't handle e.g. 64 players yet but do we really want to send that information to all of them? think about some sort of deathmatch this will mess up screen |
| 18:11 |
proller |
sapier, i can ;) |
| 18:12 |
sapier |
especially if those damn chat messages stop you from clicking formspecs ;) |
| 18:12 |
PilzAdam |
it should be done by a mod, rather than forced to everyone by hardcoding it in the engine |
| 18:13 |
proller |
maybe make it in lua by default? |
| 18:14 |
proller |
and remove hardcoded + //chat_backend.addMessage(L"", L"You died."); |
| 18:14 |
sapier |
and maybe add a config switch around it too :-) |
| 18:14 |
celeron55 |
now #1000 should work |
| 18:15 |
celeron55 |
there has been two distinct object duplication bugs |
| 18:15 |
celeron55 |
the other one i fixed already, and the other one was caused by sapier's patch |
| 18:16 |
sapier |
and the original entity loss too? |
| 18:16 |
celeron55 |
what i fixed already had existed since forever |
| 18:16 |
celeron55 |
i've fixed that correctly now |
| 18:16 |
celeron55 |
read the commit message |
| 18:17 |
celeron55 |
now, the question is, is there a third one? 8) |
| 18:18 |
sapier |
I know how to check the loss problem so this is easy to check |
| 18:20 |
sapier |
sad to tell entity loss isn't fixed |
| 18:20 |
PilzAdam |
celeron55, "item duplication"? arent we talking about object duplication? |
| 18:21 |
celeron55 |
message fixed 8) |
| 18:21 |
celeron55 |
sapier: what is your test case? |
| 18:21 |
sapier |
add a entity e.g. a cart or something else run beyond visible range and run back to that entity |
| 18:22 |
celeron55 |
oh crap, how did it work when i tested exactly that just a moment ago |
| 18:22 |
sapier |
my testcase was a cart moving out of sight by itself ... I ran behind it but it kept away |
| 18:22 |
sapier |
logging out and in brought it back |
| 18:27 |
celeron55 |
i tested it again and found one problem, which might or might not have happened to you (pull updated now) |
| 18:28 |
celeron55 |
oh, okay |
| 18:28 |
celeron55 |
it looks like that case isn't handled |
| 18:44 |
|
VanessaE joined #minetest-dev |
| 18:44 |
sapier |
tell me once I shall test again |
| 19:12 |
|
troller joined #minetest-dev |
| 19:12 |
|
proller joined #minetest-dev |
| 19:30 |
ShadowNinja |
I made rollback_check work the way I wanted. The results are limited to 5 by the query though, which I would like to change. |
| 19:39 |
|
Fadi joined #minetest-dev |
| 19:41 |
celeron55 |
sapier: now |
| 19:53 |
sapier |
way better |
| 19:53 |
celeron55 |
i am quite sure you can't get any hidden or duplicated objects now |
| 19:53 |
celeron55 |
prove me wrong |
| 19:53 |
sapier |
ran behind a cart for 10 minutes now didn't vanish once |
| 19:59 |
sapier |
celeron you didn't reverte my change for the hack is this correct or did you miss it? |
| 20:02 |
ShadowNinja |
zat: (ABS(`x`) - ABS(?)) <= ? <-- Should'nt this be "ABS(`x` - ?) <= ?"? |
| 20:05 |
ShadowNinja |
You can now see the whole rollback log if you use something like "/rollback_check 1000 10000000 1000000" :-D |
| 20:05 |
ShadowNinja |
($3 == limit) |
| 20:06 |
VanessaE |
um... help? http://pastebin.ubuntu.com/6407131/ |
| 20:06 |
VanessaE |
( ^^^^ shaders are *disabled* ) |
| 20:07 |
PilzAdam |
VanessaE, is that master, or RBAs branch? |
| 20:07 |
VanessaE |
master. |
| 20:07 |
VanessaE |
well with a bunch of my patches, but nothing I wasn't using yesterday |
| 20:08 |
PilzAdam |
whats the diff against master with your patches? |
| 20:08 |
zat |
ShadowNinja: about the abs operation, I am not sure |
| 20:08 |
zat |
I just copied it :) |
| 20:09 |
VanessaE |
PilzAdam: quite a large diff. let me just check against master first. |
| 20:09 |
PilzAdam |
VanessaE, also a verbose log when its reproduceable |
| 20:09 |
zat |
ShadowNinja: might there be some case in which both would yield different results? |
| 20:11 |
|
EvergreenTree joined #minetest-dev |
| 20:11 |
ShadowNinja |
zat: I beleive -100 == 100 there. Anyway, I was getting incorrect results, changed that, and now it works. |
| 20:13 |
ShadowNinja |
zat: I also optimized get_last_node_actor by using a limit of 1 and front() insteat of a loop that stops on the first entry. |
| 20:13 |
zat |
ShadowNinja: I am pretty sure the old code used two ABS()s too. Maybe the old code was bad too. |
| 20:13 |
ShadowNinja |
I think I will just alias it in Lua to get_node_actors(limit=1)[1] |
| 20:13 |
zat |
But nobody ever noticed since nobody ever dared to try a too big rollback_check :) |
| 20:14 |
ShadowNinja |
Of course does anything use the rollback functions other than builtin? |
| 20:14 |
zat |
idk |
| 20:14 |
|
Miner_48er joined #minetest-dev |
| 20:15 |
zat |
When I have time again I would like to make times more human friendly. So I can provide arguments such as 1m, 2d, 1w. |
| 20:19 |
ShadowNinja |
*shrug* It takes three lines in depreciated.lua to be compatible, so I'l leave it. |
| 20:19 |
VanessaE |
PilzAdam: clean build from master, currently up-to-date. terminal output, http://pastebin.ubuntu.com/6407183/ debug log, http://pastebin.ubuntu.com/6407186/ |
| 20:20 |
celeron55 |
sapier: your change for the "hack" did nothing in practice |
| 20:21 |
VanessaE |
this happens when connecting to my Realtest server ( vanessae.mine.bz 30000 ) but only when HDX is enabled. |
| 20:21 |
VanessaE |
er 30004 is realtest. doesn't happen when connecting to, say, survival (30001) |
| 20:21 |
celeron55 |
sapier: i only reverted the part that broke stuff |
| 20:23 |
sapier |
ok hope the other thing isn't wrong too |
| 20:28 |
troller |
crashing server on any lua error is annoying |
| 20:28 |
sapier |
hopfully shadow completes his fixes soon |
| 20:28 |
troller |
80% mods can crash |
| 20:29 |
troller |
2-3 times today 8( |
| 20:29 |
sapier |
that won't change ;-) |
| 20:29 |
celeron55 |
there needs to be very good error reporting if it's made to not crash |
| 20:30 |
celeron55 |
not so that you need to go look in a 100k line log |
| 20:30 |
troller |
maybe special file, or just grep in debug.log |
| 20:30 |
celeron55 |
maybe the server could write a file for each error in an error report directory |
| 20:30 |
sapier |
yet what shall server do in case of lua error ... just continue? |
| 20:30 |
VanessaE |
debug build of minetest, master branch, showing the crash on joining the offending server: http://pastebin.ubuntu.com/6407236/ |
| 20:30 |
celeron55 |
sapier: that's a problem too |
| 20:30 |
VanessaE |
with gdb backtrace. |
| 20:31 |
celeron55 |
sapier: ...actually, that's a pretty considerable problem |
| 20:31 |
troller |
sapier, break current lua function, and continue |
| 20:31 |
troller |
maybe break step |
| 20:31 |
sapier |
in worst case a mods internal data are completely messed up causing even more harm |
| 20:31 |
celeron55 |
troller: that's what javascript in browsers do... and it kind of works |
| 20:31 |
celeron55 |
so maybe it's reasonable in minetest too |
| 20:31 |
sapier |
yes but javascript usually doesn't modify your hdd |
| 20:32 |
troller |
sapier, if lua code breaked - it cant write bad data to file (in this step) |
| 20:32 |
celeron55 |
well these days there's localstorage and cookies and whatnot... but yeah, it kind of depends on the mod |
| 20:32 |
PilzAdam |
VanessaE, I cant look into that now, I have to go to sleep; bye |
| 20:32 |
VanessaE |
why is minetest fucking with shaders when I explicitly turned them off in the config? |
| 20:32 |
troller |
maybe unload mod (but it harder) |
| 20:32 |
sapier |
you think about mods not storing global data persistent for other steps |
| 20:33 |
celeron55 |
the only way to unload a mod is to reload all mods leaving that mod out |
| 20:33 |
celeron55 |
in a clean lua environment |
| 20:33 |
sapier |
might be possible |
| 20:33 |
celeron55 |
i think that functionality should be done some day |
| 20:33 |
sapier |
I guess this wouldn't be hard to do too |
| 20:34 |
sapier |
mainmenu engine is created each time a game is left this should work for scriptapi engine too |
| 20:34 |
celeron55 |
if it was possible to reload the lua environment, it would also be possible to add a new mod without dropping clients |
| 20:34 |
sapier |
wait ... the register things may be difficult |
| 20:34 |
ShadowNinja |
What should the format of the rollback_check messages be? I have "%s changed %s at %s to %s %d seconds ago." currently. |
| 20:35 |
celeron55 |
it needs syncing with clients |
| 20:35 |
celeron55 |
basically redo the initialization that is currently done only right after connecting |
| 20:35 |
sapier |
ok way more effort than initial thought ... as always :-) |
| 20:36 |
celeron55 |
and it would be quite slow and definitely noticeable to players |
| 20:37 |
sapier |
better stall for some seconds than for minutes till restart |
| 20:37 |
troller |
add or update mod |
| 20:37 |
|
werwerwer_ joined #minetest-dev |
| 20:38 |
sapier |
hmm maybe it may be even less effort to mark a mod bad in error handler and still crash server, a restart script would restart while bad marker will prevent loading of a mod on restart |
| 20:38 |
sapier |
yet that requires to find out what mod crashed the server |
| 20:38 |
celeron55 |
one option is to not implement runtime reload but rather just tell clients to reconnect automatically and restart the whole server |
| 20:38 |
celeron55 |
it would be quite easy |
| 20:39 |
celeron55 |
everything is persistent anyway |
| 20:39 |
celeron55 |
and server boot time is quite minimal |
| 20:39 |
sapier |
yes but to detect what mod crashed server we'd need to do something similar to what I do in mobf to do statistics |
| 20:40 |
celeron55 |
that'd need to be done in any case, yes |
| 20:40 |
sapier |
so each register call needs to modify the called function adding a wrapper providing the modname |
| 20:41 |
sapier |
this way we could even find out which mods cause most cpu load |
| 20:45 |
ShadowNinja |
Currently minetest.rollback_get_node_actions returns a list of http://pastebin.ubuntu.com/6407308/ Should I use tables instead of strings there? |
| 20:46 |
sapier |
shadwo is your lua errorhandler fix ready? |
| 20:47 |
ShadowNinja |
sapier: Yes, I beleive so. Have you looked it over? |
| 20:47 |
VanessaE |
so what about my crash? |
| 20:47 |
sapier |
can you reproduce it? |
| 20:47 |
VanessaE |
many times over. |
| 20:48 |
sapier |
in master too? |
| 20:48 |
VanessaE |
in master. |
| 20:48 |
sapier |
any idea how to trigger it? |
| 20:49 |
VanessaE |
lemme re-check it just to be safe |
| 20:50 |
sapier |
Shadow any chance you change LuaError back to LuaError(L,"text") I don't se any need for rotating it ;-) |
| 20:50 |
VanessaE |
oh great. Now it's going to make a liar out of me AGAIN |
| 20:50 |
VanessaE |
I'm getting sick of this shit |
| 20:51 |
ShadowNinja |
sapier: I needed to switch it to make the lua_State* optional. |
| 20:51 |
VanessaE |
sapier: I posted the results above. HDX 256px + my realtest server == crash in some obscure shaders function that should not have been being used to begin with, as shaders were disabled. |
| 20:52 |
ShadowNinja |
(Otherwise you get two backtraces or need another boolean argument. |
| 20:52 |
sapier |
is it necessary to be optional? |
| 20:54 |
sapier |
there are exactly 2 situations where you don't have a second parameter ... you need to change way more than 2 lines to rotate the parametest ... you could supply NULL in those lines and reduce the patch drasticaly |
| 20:59 |
sapier |
greate those shaders are right after reading shader configuration ... but it's just ignored :) |
| 21:01 |
VanessaE |
sapier: ok, I can reproduce it consistently with master. |
| 21:02 |
VanessaE |
same crash as noted above. get HDX 256, Turn on any or all settings you want except leave preload-item-visuals turned off. connect to vanessae.mine.bz 30004 . |
| 21:03 |
sapier |
shaders aren't exactly disabled there could you try modifying mapblock_mesh.cpp ~ L1113 http://pastebin.com/ZPkZF8X4 |
| 21:03 |
VanessaE |
um.. |
| 21:04 |
sapier |
it's a quick fix I think those materials should be defined later |
| 21:04 |
sapier |
just remove the shadermat1-bumpmaps2 block |
| 21:04 |
sapier |
replace it by those things in the pastebin |
| 21:07 |
VanessaE |
sapier: so, http://pastebin.com/8Mer7Wn4 ---> http://pastebin.com/2dtFixkR |
| 21:07 |
VanessaE |
like that? |
| 21:07 |
sapier |
seems to be fine yes |
| 21:08 |
VanessaE |
sapier: no good. |
| 21:08 |
sapier |
no build or still crashing? |
| 21:09 |
VanessaE |
still crashes, but in a different place now: |
| 21:09 |
VanessaE |
http://pastebin.ubuntu.com/6407414/ |
| 21:11 |
sapier |
ok so that bug with shaders is unrelated to your crash |
| 21:11 |
celeron55 |
seems like memory corruption to me |
| 21:12 |
troller |
die and join message from lua - https://github.com/minetest/minetest/pull/999/files need to add config option "die_broadcast" ? |
| 21:12 |
celeron55 |
run it in valgrind (and go eat your preferred kind of meal while it takes forever to danything) |
| 21:12 |
sapier |
my first thought too but it's now a completely different location yet same assertion |
| 21:12 |
celeron55 |
do anything* |
| 21:12 |
celeron55 |
that assertion is a very basic sanity check that will never fail unless memory is corrupted |
| 21:13 |
VanessaE |
want a full backtrace of it? |
| 21:13 |
VanessaE |
this is a debug builg |
| 21:13 |
VanessaE |
build* |
| 21:14 |
sapier |
or reqeuests within texture queue are messed up yet I don't see a reason why a mutex queue should be messed up |
| 21:15 |
VanessaE |
here's what's left on the minetest window at the time of the crash: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011122013%20-%2004:13:36%20PM.png --- and here's the full debug + backtrace from gdb: http://pastebin.ubuntu.com/6407451/ |
| 21:16 |
celeron55 |
sapier: i have never seen that queue system fail in any way whatsoever |
| 21:16 |
celeron55 |
sapier: and it has been there since the start of time |
| 21:16 |
celeron55 |
so it seems unlikely |
| 21:17 |
|
Taoki joined #minetest-dev |
| 21:17 |
sapier |
I don't see any way how this could fail in code too ... yes I know thats no guarantee it isn't there :-) |
| 21:18 |
sapier |
I vague remember a similar problem months ago |
| 21:22 |
VanessaE |
switching to a smaller size of HDX (e.g. 128px instead of my usual 256 px) or disabling it entirely is enough to get around the crash, if that tells you anything at all. |
| 21:22 |
celeron55 |
so is valgrind impossible? |
| 21:22 |
VanessaE |
and earlier 256px with preload item visuals turned *ON* also worked. |
| 21:22 |
VanessaE |
I have valgrind, but I don't have a clue how to use it |
| 21:22 |
VanessaE |
(haven't had a chance to research) |
| 21:22 |
sapier |
does that strange png warning occur with smaller textures too? |
| 21:22 |
celeron55 |
well, "valgrind bin/minetest" |
| 21:23 |
sapier |
just run valgrind minetest and post results |
| 21:23 |
VanessaE |
oh just that? sure. |
| 21:23 |
celeron55 |
valgrind is like magic... magic that burns infinite CPU |
| 21:23 |
sapier |
be prepared to wait ... minetest will get really slow |
| 21:23 |
VanessaE |
ok, off it goes. |
| 21:24 |
celeron55 |
it makes everything about 50 times slower 8) |
| 21:24 |
VanessaE |
heh |
| 21:24 |
sapier |
imho 50 is average :) |
| 21:24 |
sapier |
can be 100 too |
| 21:25 |
VanessaE |
weird. under valgrind it's fine, if slow . |
| 21:25 |
celeron55 |
it also consumes multiple times the amount of memory |
| 21:25 |
ShadowNinja |
Can serialized node metadata contain nul? |
| 21:26 |
sapier |
it doesn't crash within valgrind? |
| 21:26 |
VanessaE |
sapier: nope. |
| 21:26 |
celeron55 |
valgrind results in a slightly varied memory layout which maybe places the corruption in a more lucky place |
| 21:27 |
sapier |
yes but it should warn anyway could you post the valgrind output somewhere? |
| 21:27 |
VanessaE |
shall I quit from the program now? |
| 21:27 |
sapier |
yes |
| 21:27 |
celeron55 |
it doesn't know the "intention" of any memory access |
| 21:27 |
VanessaE |
sapier: sure, sec. |
| 21:28 |
celeron55 |
it can only check for segfaults and uninitialized memory, which won't happen in the "right" circumstances |
| 21:28 |
sapier |
no it doesn't know intention but chance to acces somewhere beyond is way better than correct access |
| 21:28 |
celeron55 |
it is, but it doesn't always happen; i have had many such experiences |
| 21:28 |
sapier |
I know but it's a chance |
| 21:30 |
sapier |
at least if you don't have a more promissing suggestion? |
| 21:30 |
VanessaE |
waiting for gedit to capture the whole output from a second run... |
| 21:30 |
sapier |
*g* |
| 21:30 |
VanessaE |
"==26849== More than 1000 different errors detected. I'm not reporting any more." |
| 21:30 |
VanessaE |
HA! |
| 21:31 |
celeron55 |
if i was VanessaE, i would implement some kind of a global function that walks through and sanity-checks TextureSource's queue and abort()s if it's not valid, and call it basically absolutely everywhere in order to bisect where it gets corrupt |
| 21:31 |
sapier |
another option is printf debugging (output of values) |
| 21:32 |
sapier |
:-) sounds like something one of my collegues did .... just to realize memory handling is fine and a invalid destructor got called :-) |
| 21:33 |
VanessaE |
(or I could just use the --log-file switch in valgrind, duh) |
| 21:33 |
sapier |
vanessa is 256x texturepack only requirement? |
| 21:33 |
celeron55 |
i debugged one thing at work with that kind of an approach... and in the end i found i didn't yet really understand what i should be searching for 8) |
| 21:34 |
VanessaE |
sapier: seems that at present, either 256 or 512px will crash it, but 128 doesn't. |
| 21:34 |
sapier |
it's quite normal ... just some days ago I did search a week for some communication handling error just to realize it was a obscure endianess bug |
| 21:34 |
sapier |
ok I try to reproduce |
| 21:35 |
VanessaE |
try other sizes also, if you can |
| 21:35 |
VanessaE |
thing is: Realtest is mostly UNSUPPORTED in HDX. |
| 21:35 |
VanessaE |
so why it even crashes at all, is a big mystery |
| 21:36 |
sapier |
do I need to install realtest too? |
| 21:36 |
VanessaE |
only, basically, the stuff from minetest_game default is found here. |
| 21:36 |
VanessaE |
no, just connect to vanessae.mine.bz 30004 |
| 21:36 |
sapier |
first I need to find your texture pack |
| 21:37 |
celeron55 |
it would be useful to poke memory in the core dump around where result.key and name are |
| 21:37 |
VanessaE |
screenshot of the client running under valgrind, successfully: http://digitalaudioconcepts.com/vanessa/hobbies/minetest/screenshots/Screenshot%20-%2011122013%20-%2004:36:27%20PM.png |
| 21:37 |
celeron55 |
using gdb |
| 21:37 |
celeron55 |
like, just dump out some thousands of raw bytes |
| 21:37 |
celeron55 |
the data going there might be identifiable |
| 21:38 |
VanessaE |
good idea |
| 21:38 |
celeron55 |
and... to do that, use: google |
| 21:38 |
sapier |
I'd first try errorstreaming key and name ... quick to do |
| 21:38 |
celeron55 |
i bet nobody in this world remembers how to print out correctly formatted stuff in gdb |
| 21:38 |
VanessaE |
ok, got it crashed in gdb. how do I do that memory dump? |
| 21:38 |
VanessaE |
haha |
| 21:38 |
VanessaE |
ok |
| 21:39 |
* VanessaE |
googles |
| 21:39 |
|
Fadi joined #minetest-dev |
| 21:39 |
sfan5 |
PilzAdam would tell you to not use google now :P |
| 21:40 |
VanessaE |
ok first I gotta find the address of the crash |
| 21:40 |
VanessaE |
#2 0x00000000006ac080 in assert_fail (assertion=assertion entry=0xb52dd6 "result.key == name", |
| 21:40 |
VanessaE |
there? |
| 21:41 |
sapier |
ok 256 isn't enough |
| 21:41 |
sapier |
I used your photorealistic pack did you use another one? |
| 21:42 |
VanessaE |
sapier: this one, https://github.com/VanessaE/hdx-256 |
| 21:45 |
sapier |
ok that's a different one |
| 21:46 |
troller |
https://github.com/codetiger/IrrNacl https://developers.google.com/native-client/pnacl-preview/overview ... |
| 21:49 |
celeron55 |
VanessaE: are you still at that gdb prompt? |
| 21:49 |
VanessaE |
yes |
| 21:49 |
VanessaE |
and the web is as cryptic as ever when it comes to telling a noob how to operate a program like gdb :P |
| 21:50 |
celeron55 |
this is the best guide there is, but i'll tell you exactly what to do http://www.delorie.com/gnu/docs/gdb/gdb_56.html |
| 21:50 |
VanessaE |
heh, I'm on that page now. |
| 21:50 |
celeron55 |
so tell this to gdb: |
| 21:50 |
celeron55 |
print result.key |
| 21:50 |
celeron55 |
print name |
| 21:50 |
celeron55 |
print &result.key |
| 21:50 |
celeron55 |
print &name |
| 21:50 |
celeron55 |
...actually, leave those two later ones out |
| 21:51 |
VanessaE |
http://pastebin.ubuntu.com/6407635/ |
| 21:51 |
VanessaE |
um. ouch :) |
| 21:51 |
celeron55 |
print result then |
| 21:51 |
celeron55 |
-then |
| 21:51 |
VanessaE |
(gdb) print result |
| 21:51 |
VanessaE |
$2 = '\000' <repeats 113 times> |
| 21:51 |
celeron55 |
8) maybe i'll use some quotes |
| 21:52 |
celeron55 |
gah, give me the backtrace |
| 21:52 |
VanessaE |
coming right up. |
| 21:52 |
VanessaE |
http://pastebin.ubuntu.com/6407647/ |
| 21:52 |
sapier |
still not crashing ... I'm trying to connect to your server |
| 21:54 |
sapier |
do I need to enable or disable preloading? |
| 21:55 |
VanessaE |
disable. |
| 21:55 |
celeron55 |
okay so for gdb: "frame 3" |
| 21:55 |
celeron55 |
then try print result |
| 21:56 |
VanessaE |
http://pastebin.ubuntu.com/6407668/ |
| 21:56 |
celeron55 |
and "print name" |
| 21:57 |
VanessaE |
(gdb) print name |
| 21:57 |
VanessaE |
$4 = (const std::string &) @0x7fffe4a159f0: {static npos = <optimized out>, |
| 21:57 |
VanessaE |
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7fffd017d488 "default_torch_animated.png^[verticalframe:16:0"}} |
| 21:57 |
VanessaE |
(those torch images have not been modified since June) |
| 21:58 |
celeron55 |
okay so |
| 21:58 |
sapier |
ok worksforme ... :-/ |
| 21:59 |
celeron55 |
"default_torch_on_ceiling_animated.png^[verticalframe:16:0" <- result.key |
| 21:59 |
celeron55 |
"default_torch_animated.png^[verticalframe:16:0" <- name |
| 21:59 |
celeron55 |
so the string itself isn't borked but something where the string comes is |
| 22:00 |
celeron55 |
and it's borked in some very fine way that doesn't break it completely |
| 22:01 |
VanessaE |
can I break 'em or can't I? :) |
| 22:01 |
sapier |
If I'd not know better I'd say wrong thing was returned |
| 22:02 |
celeron55 |
seems quite impossible to debug this way |
| 22:02 |
celeron55 |
we need a more blatant crash |
| 22:03 |
celeron55 |
and a more early one |
| 22:03 |
VanessaE |
"more blatant"...erm.. |
| 22:03 |
VanessaE |
:) |
| 22:04 |
sapier |
vanessa you do run this on linux? |
| 22:04 |
VanessaE |
sapier: yep |
| 22:04 |
sapier |
what distribution? |
| 22:04 |
VanessaE |
Xubuntu 13.10 |
| 22:04 |
VanessaE |
(inb4 lol ubuntu sux) |
| 22:04 |
sapier |
hmm a little bit more recent than by debian |
| 22:04 |
sapier |
yet not that far away |
| 22:05 |
sapier |
and you run with current master |
| 22:05 |
VanessaE |
yep, this is a clean build, no extra patches. |
| 22:05 |
celeron55 |
how about just plain git bisect? |
| 22:05 |
celeron55 |
can't really know if something would pop up or not |
| 22:06 |
VanessaE |
maybe I could dump the core and put that up for download. |
| 22:06 |
sapier |
still doesn't crash for me :-/ |
| 22:07 |
celeron55 |
it's not useful; it's probably practically impossible to dig through the std::list pointer structure to find out where in it is a problem if it's such a small difference |
| 22:07 |
sapier |
maybe a texture queue trace would help |
| 22:08 |
celeron55 |
VanessaE: gdb: "print m_get_texture_queue" |
| 22:09 |
celeron55 |
also "print result_queue" |
| 22:09 |
VanessaE |
ok. Starting from a fresh run. I need frame 3 again? |
| 22:10 |
sapier |
yes |
| 22:10 |
celeron55 |
yes, assuming the backtrace looks the same |
| 22:10 |
VanessaE |
yep, seems the same. |
| 22:10 |
VanessaE |
sec. |
| 22:10 |
sapier |
celeron is there any special reason why this is done as mutex queue not as semaphore variant? except of jthread not supporting semaphore? |
| 22:11 |
VanessaE |
http://pastebin.ubuntu.com/6407734/ |
| 22:11 |
celeron55 |
the only reason for anything is that i did it with plain jthread |
| 22:11 |
sapier |
ok because i implemented jsemaphore for async things ... i don't like thise active sleeping things |
| 22:14 |
celeron55 |
remember to have the timeout there or some other means to let it quit on shutdown of the program without getting a result |
| 22:15 |
celeron55 |
VanessaE: nothing obvious there; git bisect is your friend 8) |
| 22:15 |
VanessaE |
bisect!? *shudder* |
| 22:16 |
sapier |
or tell us more precise how to reproduce it ;-) |
| 22:17 |
VanessaE |
sapier: what if I sent you my minetest binary? can you run an amd64 build? |
| 22:17 |
sapier |
worth a try |
| 22:17 |
VanessaE |
catch. |
| 22:17 |
VanessaE |
81 MB |
| 22:18 |
sapier |
81MB ... wooo |
| 22:19 |
VanessaE |
this is built against luajit, leveldb, curl, and irrlicht 1.8 |
| 22:19 |
sapier |
ok chances this will run are minor |
| 22:20 |
sapier |
no leveldb no irrlicht-1.8 and no luajit ... last on would be quite easy to fix others ... especialy irrlicht is a problem on debian |
| 22:21 |
VanessaE |
lemme try rebuilding against 1.7.3 and without the others |
| 22:22 |
celeron55 |
you could also try valgrind --tool=helgrind |
| 22:22 |
celeron55 |
if it's a thread locking issue |
| 22:23 |
celeron55 |
but i don't know what to expect from there |
| 22:23 |
VanessaE |
hm, there's no cmake option to disable luajit? |
| 22:24 |
celeron55 |
oh wow |
| 22:24 |
celeron55 |
i tried helgrind and minetest crashed to SIGILL |
| 22:24 |
VanessaE |
eek |
| 22:25 |
celeron55 |
apparently helgrind didn't like luajit 8 |
| 22:25 |
celeron55 |
8)* |
| 22:25 |
VanessaE |
heh |
| 22:25 |
|
Gronx joined #minetest-dev |
| 22:26 |
celeron55 |
and no, there doesn't seem to be a cmake option for luajit |
| 22:27 |
VanessaE |
sapier: I had to cancel the dcc |
| 22:28 |
sapier |
no problem most likely it wouldn't have run for me |
| 22:28 |
VanessaE |
ok, I compiled against 1.7.3, no curl, no leveldb |
| 22:28 |
sapier |
ok helgrinding now ... this is even more slow than normal valgrind :-) |
| 22:28 |
VanessaE |
still getting the same crash |
| 22:29 |
sapier |
ok if you send me this version chances it will run for me are better |
| 22:29 |
VanessaE |
sure, sec. |
| 22:30 |
VanessaE |
uploading it to my web space so both of you can grab it |
| 22:30 |
VanessaE |
http://digitalaudioconcepts.com/vanessa/hobbies/minetest/minetest |
| 22:34 |
* VanessaE |
attempts to bisect (been years since I did this last) |
| 22:37 |
VanessaE |
you know what, screw it. I'm going all the way back to 0.4.0 and tracking this down once and for all :) |
| 22:41 |
sapier |
sorry doesn't work I'm 3 glibc versions behind |
| 22:45 |
VanessaE |
bummer. |
| 22:46 |
sapier |
debian ;-) rock solid but outdated ;-) |
| 22:46 |
VanessaE |
heh |
| 22:49 |
sapier |
is there any special place on map maybe? |
| 22:50 |
VanessaE |
over by my home, -366,36.-1215 |
| 22:50 |
VanessaE |
er -366,36,-1215 |
| 22:51 |
sapier |
ok no idea how to get there but I don't think this is a realistic reason too |
| 22:52 |
VanessaE |
whoa, that's fucked up |
| 22:53 |
VanessaE |
it does not crash if I load the same world in singleplayer |
| 22:53 |
VanessaE |
(as in, cp -av /path/to/server ~/.minetest/worlds ) |
| 22:53 |
sapier |
do you use a texture pack localy or download it? |
| 22:53 |
VanessaE |
download? eh? |
| 22:53 |
sapier |
ok so local :-) |
| 22:53 |
VanessaE |
oh, you mean HDX? it's my local copy, symlinked from its usual storage dir into ~/.minetest/textures |
| 22:54 |
VanessaE |
lrwxrwxrwx 1 vanessa vanessa 54 Nov 12 15:54 HDX-256px -> /home/vanessa/Minetest-related/texture-packs/HDX/256px |
| 23:06 |
sapier |
vanessae enabling tile.cpp L 784 might help |
| 23:06 |
VanessaE |
sec |
| 23:07 |
VanessaE |
I'm redoing my system to clearly separate my servers' build tree from my local client. |
| 23:07 |
VanessaE |
s/system/build system/ |
| 23:10 |
|
Taoki joined #minetest-dev |
| 23:13 |
sapier |
i hate templates |
| 23:13 |
kaeza |
amen |
| 23:20 |
sapier |
wait i think there is a generic problem in there |
| 23:20 |
sapier |
Thread A requests texture and gets scheduled before doing pop_front |
| 23:21 |
sapier |
hmm forget about it ... different queues |
| 23:28 |
VanessaE |
ok, I cannot reproduce the crash if I load the map in singleplayer. |
| 23:30 |
sapier |
my guess is a very very rare timing bug in our thread handling I don't have any idea what that callerdata/id thing is supposed to do maybe it's correct maybe not ... at least is seems to be the only thing that may be involved (except a generic memory access error) |
| 23:30 |
sapier |
I'll have a closer look at this tomorrow |
| 23:31 |
|
sapier left #minetest-dev |
| 23:31 |
VanessaE |
fwiw I have not yet started that bisect. I'm making 100% sure I didn't break anything |
| 23:33 |
ShadowNinja |
Thoughts? https://github.com/ShadowNinja/minetest/compare/sqlite_rollback |
| 23:36 |
ShadowNinja |
VanessaE: Care to try that? :-) /rollback_check takes about 0.1s now on a old copy of my server rollback(7826433 entries). |
| 23:36 |
VanessaE |
maybe later on after I come to some conclusion with this client bug |
| 23:48 |
VanessaE |
ok, I purged every last minetest-related thing from my box (except backups and my servers' files), re-installed a server-only build, completely from scratch, with only shadow's pcall_errfunc patch. The servers are behaving normally. The client is a run-in-place build, 100% clean upstream, and is stored and run totally separate from the servers. It still crashes exactly as before. |
| 23:51 |
VanessaE |
but that's only the client connecting to the server - I can't reproduce the crash when running the very same map in singleplayer. |
| 23:58 |
VanessaE |
http://pastebin.ubuntu.com/6408110/ |
