| Time |
Nick |
Message |
| 00:05 |
VanessaE |
and it just occurred to me that I can't bisect back past July 22, else I won't be able to connect to the offending server. |
| 00:10 |
VanessaE |
crap. |
| 00:11 |
VanessaE |
ok, in the middle of the bisect, I hit a point where I cannot connect to the offending server because of version differences. What do I do? mark this point as 'good'? |
| 00:15 |
VanessaE |
seems I need, git bisect skip |
| 00:19 |
|
NakedFury joined #minetest-dev |
| 00:21 |
VanessaE |
ah HAH! I found a good commit :D |
| 00:21 |
* VanessaE |
keeps going. |
| 00:22 |
|
EvergreenTree joined #minetest-dev |
| 00:24 |
VanessaE |
git bisect says I found it: http://pastebin.ubuntu.com/6408186/ |
| 00:25 |
VanessaE |
proller, you bwoke it! :( |
| 00:25 |
VanessaE |
troller ^^ |
| 00:25 |
|
NakedFury joined #minetest-dev |
| 00:27 |
VanessaE |
re-checking with the commit immediately preceding it |
| 00:30 |
VanessaE |
except no. that's not actually true |
| 00:31 |
VanessaE |
going backward in the history now. |
| 00:47 |
VanessaE |
ok, that settles that. whatever the bug is, it predates 0e89bca173fb000368786e5c9f5614e506737b92 which is the oldest I can go and still be able to connect to the offending server. |
| 00:52 |
|
Taoki[laptop] joined #minetest-dev |
| 00:59 |
|
OWNSyouAll joined #minetest-dev |
| 01:02 |
VanessaE |
any comments on this or an I just wasting my time? :P |
| 01:07 |
|
djdduty joined #minetest-dev |
| 01:09 |
|
djdduty joined #minetest-dev |
| 01:10 |
|
Miner_48er joined #minetest-dev |
| 01:26 |
|
OWNSyouAll joined #minetest-dev |
| 01:59 |
VanessaE |
um, shouldn't run-in-place also cause minetestserver to pull from its own directory? |
| 01:59 |
VanessaE |
e.g. for worlds and game files |
| 02:04 |
VanessaE |
ok, got that working (had to install the desired game globally, specify the world with the --world directive instead of --worldname). client still crashes connecting to the copy. |
| 02:04 |
VanessaE |
(expected) |
| 02:14 |
|
RealBadAngel joined #minetest-dev |
| 02:22 |
|
Taoki joined #minetest-dev |
| 02:25 |
ShadowNinja |
zat: https://github.com/minetest/minetest/pull/1001 |
| 02:33 |
|
Taoki joined #minetest-dev |
| 02:42 |
|
ecube joined #minetest-dev |
| 02:44 |
|
zork_ joined #minetest-dev |
| 03:22 |
VanessaE |
Ok, I think I got something! |
| 03:26 |
VanessaE |
I think it's the texture extrude code. I have some jungle grass in my inventory. Removing it from my inventory by placing it into a chest stops the crash. My theory: HDX junglegrass, wild grass, and several other plantlike textures have a high amount of detail and a high ratio of on-to-transparent pixels in their textures. |
| 03:26 |
VanessaE |
I removed it from my inventory by first removing the mod that creates it, logging in, moving the item to a chest, then logging back out, re-adding the mod, and logging back in. |
| 03:28 |
VanessaE |
a high ratio of on:transparent pixels is known to drag the extrude code through the mud, and those jungle grass textures are offenders. |
| 03:29 |
VanessaE |
I know I've been complaining about this code being slow, but this goes beyond that. Simply having that object in my inventory when I sign on is enough to trigger the client crash. |
| 03:33 |
VanessaE |
this may also be why having preload visuals enabled also seems to avoid the crash, since the extrude code is not being called while the map is loading. |
| 03:33 |
VanessaE |
remember that first-open-of-inventory-crash bug? I believe the two are related. |
| 03:47 |
|
OWNSyouAll joined #minetest-dev |
| 03:51 |
VanessaE |
this inventory file contains sufficient items to cause the client to crash: http://pastebin.ubuntu.com/6408813/ |
| 03:56 |
VanessaE |
change the "name = " line to "singleplayer", of course. |
| 04:00 |
|
smoke_fumus joined #minetest-dev |
| 04:00 |
|
ImQ009 joined #minetest-dev |
| 04:14 |
VanessaE |
preload item visuals probably needs to be turned OFF for this test to work |
| 04:37 |
RealBadAngel |
confirmed the bug, on windows client it hangs client completely |
| 04:37 |
RealBadAngel |
no error messages, just hanging dead |
| 04:40 |
VanessaE |
fwiw, I set RealBadAngel's account up on the test server such that he has the player file above (with his name inserted). |
| 05:07 |
|
OWNSyouAll joined #minetest-dev |
| 06:11 |
|
Weedy_lappy joined #minetest-dev |
| 06:40 |
|
OldCoder joined #minetest-dev |
| 06:50 |
|
mrtux joined #minetest-dev |
| 07:04 |
|
cornernote joined #minetest-dev |
| 07:05 |
|
cornernote left #minetest-dev |
| 08:02 |
|
Jordach joined #minetest-dev |
| 08:18 |
|
Jordach joined #minetest-dev |
| 08:57 |
|
darkrose joined #minetest-dev |
| 09:46 |
|
proller joined #minetest-dev |
| 09:46 |
|
troller joined #minetest-dev |
| 10:03 |
|
KingsleyT joined #minetest-dev |
| 10:12 |
celeron55 |
cornernote requested me to remove his ban, and i did |
| 10:18 |
Jordach |
...explains why he's in #minetest |
| 10:18 |
|
khonkhortisan joined #minetest-dev |
| 10:47 |
|
EvergreenTree joined #minetest-dev |
| 11:44 |
|
Fadi joined #minetest-dev |
| 11:44 |
Fadi |
Hey guys |
| 11:44 |
Fadi |
how do I make my block just appear as an item |
| 11:44 |
Fadi |
the wiki doesn't really explain much |
| 12:48 |
|
khonkhortisan joined #minetest-dev |
| 13:13 |
|
bas080 joined #minetest-dev |
| 13:15 |
|
ImQ009 joined #minetest-dev |
| 13:17 |
|
hmmmm joined #minetest-dev |
| 13:56 |
|
troller joined #minetest-dev |
| 13:56 |
|
proller joined #minetest-dev |
| 14:06 |
Fadi |
So I'm trying to get my wood block to form as a tree but I don't know what to use and the wiki isn't really that helpful |
| 14:06 |
Fadi |
any ideas? |
| 14:11 |
kaeza |
Fadi, please don't post modding questions in here. this channel is strictly for core engine discussion |
| 14:11 |
Fadi |
oh |
| 14:11 |
kaeza |
consider using #minetest instead |
| 14:11 |
Fadi |
I thought because of "dev" it meant for mod development |
| 14:11 |
|
Fadi left #minetest-dev |
| 14:47 |
|
proller joined #minetest-dev |
| 14:52 |
|
Taoki joined #minetest-dev |
| 15:15 |
|
zat joined #minetest-dev |
| 15:24 |
|
NakedFury joined #minetest-dev |
| 15:56 |
|
EvergreenTree joined #minetest-dev |
| 16:06 |
|
Akien joined #minetest-dev |
| 16:15 |
|
iqualfragile joined #minetest-dev |
| 16:24 |
ShadowNinja |
Comments on #995 and/or #1001? |
| 16:42 |
VanessaE |
how about on my rather lengthy report last night? (and RBA's confirmation of same) |
| 16:43 |
|
djdduty joined #minetest-dev |
| 16:46 |
|
zork__ joined #minetest-dev |
| 16:51 |
celeron55 |
kahrl could be interested as he has made the extrusion code |
| 16:51 |
VanessaE |
celeron55: ok. At least I finally managed to come up with a way to reproduce the crash reliably :) |
| 17:21 |
|
hax404 joined #minetest-dev |
| 17:33 |
|
sapier joined #minetest-dev |
| 17:37 |
|
sapier1 joined #minetest-dev |
| 17:37 |
|
sapier1 left #minetest-dev |
| 17:38 |
|
sapier joined #minetest-dev |
| 17:39 |
|
Jordach joined #minetest-dev |
| 17:48 |
sapier |
Does anyone have an idea what Caller and Callerdata are supposed to do in ResultsQueue? as far as J can see the only thing they do is not add a new destination queue if key as well as caller are equal. This is not a bug but may result in strange things if not handled properly. And there is no documentation how to handle it properly ;-) |
| 17:50 |
celeron55 |
uhm |
| 17:50 |
celeron55 |
well the only one who has ever known how that thing works is me, and i have forgotten everything about it during these years |
| 17:51 |
sapier |
if I interpret code correct caller should be a unique id beeing linked to a destination queue |
| 17:51 |
sapier |
while callerdata seems to be data that should be passed back to caller |
| 17:52 |
celeron55 |
sounds like a very reasonable interpretation |
| 17:52 |
sapier |
took some time to find out ;-) |
| 17:52 |
sapier |
at least this way the queue does make some sense |
| 17:52 |
celeron55 |
and they both need to be copyable types |
| 17:53 |
sapier |
anything with a copy constructor is copyable |
| 17:53 |
sapier |
yet this feature isn't used anywhere by now |
| 17:53 |
celeron55 |
i meant that |
| 17:53 |
sapier |
0,0 is used everywhere ... everywhere beeing 3 cases :-) |
| 17:55 |
sapier |
I guess I add that information to the header may save someone time to do investigation again |
| 17:56 |
celeron55 |
i recall one of the main features of the thing is that if there are many requests for the same thing, they don't get separately queued but rather are simply added as receivers in the request that already is queued |
| 17:56 |
celeron55 |
s/same thing/same resource/ |
| 17:56 |
sapier |
if that was intended I don't see any mechanism that would do this |
| 17:57 |
celeron55 |
and each generateable resource is identified by Key, which is practically std::string |
| 17:57 |
sapier |
at least not within the queue |
| 17:57 |
celeron55 |
uh |
| 17:57 |
celeron55 |
it's pretty clearly visible |
| 17:57 |
sapier |
it's stored yes but how is it handled on fetching? |
| 17:57 |
celeron55 |
the thing commented as "If the caller is already on the list, only update CallerData" |
| 17:58 |
celeron55 |
the comment seems to be somewhat misleading |
| 17:58 |
sapier |
yes :-) the in direction is clear |
| 17:58 |
celeron55 |
but the code does what i said |
| 18:00 |
|
PilzAdam joined #minetest-dev |
| 18:00 |
celeron55 |
hmm |
| 18:00 |
celeron55 |
how the fuck does the return of the data to whoever asked for it works |
| 18:00 |
sapier |
what I agree is that requests for same key by multiple callers get merged to a single request with callers stored in a list within that request |
| 18:01 |
celeron55 |
at around eg. tile.cpp:791 is the handling of one of such queues, but... wtf |
| 18:01 |
sapier |
that's my point the destination queue of the second request is never stored |
| 18:02 |
sapier |
I don't se any mechanism this one will ever get a result |
| 18:02 |
celeron55 |
it seems that there is some kind of a bug in it |
| 18:03 |
celeron55 |
the multiple callers functionality is not used by anything though so that's why it doesn't matter currently |
| 18:03 |
sapier |
that's the good point about it |
| 18:03 |
celeron55 |
hmm, or is it? |
| 18:03 |
celeron55 |
is it used, i mean |
| 18:04 |
sapier |
no everyone uses it with 0,0 I think whoever tried to create multithread texture loading may have had issues with this |
| 18:04 |
celeron55 |
i think 0,0 shouldn't matter |
| 18:04 |
sapier |
so what now remove or fix? |
| 18:04 |
celeron55 |
or does it... uh |
| 18:05 |
celeron55 |
ah oh yes, caller should be different for each thread that requests stuff |
| 18:05 |
celeron55 |
(basically get_current_thread_id() should work in it) |
| 18:06 |
celeron55 |
if it's changed to u64 or whatever that returns |
| 18:06 |
celeron55 |
i think fixing it isn't too hard |
| 18:06 |
celeron55 |
and fixing it could be very useful in the future |
| 18:07 |
celeron55 |
shouldn't just moving *dest into CallerInfo fix it? |
| 18:07 |
sapier |
just wanted to suggest this |
| 18:08 |
|
Calinou joined #minetest-dev |
| 18:08 |
sapier |
and of course on handling the request the request has to be filled to ALL request queues |
| 18:08 |
celeron55 |
yes |
| 18:09 |
celeron55 |
also some comments should be corrected |
| 18:09 |
sapier |
and we should add documention to make clear callerid has to be unique |
| 18:09 |
sapier |
ok I'm gonna fix and create a pull request for review |
| 18:10 |
celeron55 |
as for comments: "If the caller is already on the list, only update CallerData" should be in the if(request.key == key) block, and in place of it should be "If the request for this resource is already queued, only add requester" |
| 18:10 |
celeron55 |
or something like that |
| 18:13 |
celeron55 |
CallerData is designed to allow the caller to attach some kind of a context to the data if it wants to; dunno if there will ever be use for it |
| 18:14 |
sapier |
Sometimes this is quite usefull |
| 18:14 |
celeron55 |
s/context to the data/context to the request-response/ |
| 18:15 |
sapier |
hmm the reply contains the callerdata :-) guess I need to be carefull not to create to many cycles there :-) |
| 18:18 |
sapier |
Ok due to templating this is more tricky then I tought |
| 18:24 |
celeron55 |
you need to add like a million more template parameters to CallerInfo |
| 18:25 |
celeron55 |
well Key and T |
| 18:25 |
sapier |
yea that's what I meant with "more tricky" |
| 18:25 |
celeron55 |
shouldn't need more than that (except changing everything to provide those to it then) |
| 18:28 |
|
Zeitgeist_ joined #minetest-dev |
| 18:29 |
|
EvergreenTree joined #minetest-dev |
| 18:31 |
sapier |
can templates be forward declared? |
| 18:34 |
sapier |
no can't CallerInfo requires ResultQueue --> requires GetResult --> requires CallerInfo ... loop closed |
| 18:40 |
kaeza |
an user on my server is having this problem: http://i.imgur.com/JpT7Ro5.png?1 |
| 18:41 |
sapier |
what's the problem? |
| 18:41 |
kaeza |
he's using latest git now (the screenshot is before update), but the problem persists |
| 18:41 |
kaeza |
sapier, the inventory looks "squashed" |
| 18:42 |
sapier |
ok that's not intended to be that way :-) |
| 18:42 |
ShadowNinja |
And cloned. kaeza: It works for you with latest git? |
| 18:42 |
kaeza |
it does |
| 18:43 |
kaeza |
I thought it may be due to that getOriginalSize vs getSize error as he was having that problem with the tiled menu logo; updating fixed that, but the inventory issue persists |
| 18:44 |
|
Taoki joined #minetest-dev |
| 18:44 |
ShadowNinja |
kaeza: What version was he at previously? |
| 18:45 |
kaeza |
ShadowNinja, he was using sfan5's build, from this commit: https://github.com/minetest/minetest/commit/68bbdf1b2c1bc70f48d52694411cd7859d09c728 |
| 18:45 |
kaeza |
err |
| 18:46 |
kaeza |
a924409 |
| 18:46 |
kaeza |
"Masterserver update" Date: Fri Oct 18 01:32:49 2013 +0400 |
| 18:47 |
kaeza |
he's now at 5094a39 |
| 18:49 |
ShadowNinja |
sapier: In #1002 shouldn't that be outside of the loop? Just put a if statement around the shader generating. |
| 18:56 |
|
OldCoder joined #minetest-dev |
| 18:58 |
|
proller joined #minetest-dev |
| 18:58 |
sapier |
loop? oops :-) |
| 19:02 |
sapier |
ironicaly I gave exactly the new fixed version to vanessae yesterday :-) |
| 19:03 |
sapier |
not the silly version I originally created as pull request |
| 19:09 |
|
thexyz joined #minetest-dev |
| 19:32 |
|
sapier joined #minetest-dev |
| 19:40 |
|
Ethan__ joined #minetest-dev |
| 20:02 |
|
salamanderrake joined #minetest-dev |
| 20:25 |
|
addi joined #minetest-dev |
| 20:38 |
|
werwerwer joined #minetest-dev |
| 20:42 |
|
EvergreenTree joined #minetest-dev |
| 20:43 |
kahrl |
VanessaE: good that you found a reliable way to reproduce the crash. I once linked you to a patch that disabled the whole extrusion routine... if you apply that, does it still crash? |
| 20:47 |
sapier |
https://github.com/sapier/minetest/commit/ca33c936bf52690f4ade20fc9a84755fec268450 my suggestion how multicaller support could be fixed |
| 20:47 |
sapier |
plz review this is heavyly templated code I usually don't use that much templates so my confindence in correctness isn't really high |
| 20:49 |
|
djdduty joined #minetest-dev |
| 20:56 |
|
damiel joined #minetest-dev |
| 20:56 |
|
damiel joined #minetest-dev |
| 21:01 |
|
Miner_48er joined #minetest-dev |
| 21:13 |
|
OWNSyouAll joined #minetest-dev |
| 21:35 |
|
damiel joined #minetest-dev |
| 21:39 |
VanessaE |
kahrl: I'm afraid I no longer have that patch. Got it handy? :) |
| 21:42 |
|
smoke_fumus joined #minetest-dev |
| 21:44 |
kahrl |
well I don't either, but it's trivial ;) |
| 21:45 |
VanessaE |
ok, what do I hack into? ;) |
| 21:46 |
kahrl |
http://pastebin.ubuntu.com/6412895/ |
| 21:46 |
kahrl |
now that I looked at that code... |
| 21:47 |
kahrl |
it apparently uses CMeshBuffer::append which is *very* slow according to the comment above PreMeshBuffer |
| 21:47 |
kahrl |
I guess simply using PreMeshBuffer in the extrude routine might speed it up a bit |
| 21:49 |
VanessaE |
shall I apply this patch and test, or would you rather do ^^^^ that and I should wait for the result? |
| 21:49 |
kahrl |
you can test it |
| 21:49 |
VanessaE |
ok |
| 21:49 |
kahrl |
I haven't reproduced the crash yet so I'd have to do that first |
| 21:52 |
VanessaE |
the crash is easy. Install HDX 256 ( https://github.com/VanessaE/hdx-256 ) and activate it. Install the Realtest game ( https://github.com/DanDuncombe/realtest ) and create a new world. Install this player file http://pastebin.ubuntu.com/6408813/ into that new world, but change the "name =" line to singleplayer or whatever. Start the game with that world and it should either crash or hang. |
| 21:58 |
VanessaE |
kahrl: it does NOT crash with your patch installed. |
| 22:00 |
sapier |
it doesn't crash ingame too ... so this only happens on startup only |
| 22:02 |
VanessaE |
correct. |
| 22:12 |
sapier |
wow :-) vanessa in your case at least two other threads are critical |
| 22:13 |
sapier |
critical meaning some state that may be related to your issue |
| 22:19 |
|
OWNSyouAll joined #minetest-dev |
| 22:22 |
sapier |
lol VanessaE once you add debug traces the error doesn't occur any longer |
| 22:23 |
Exio4 |
it is a race condition, if the stuff is too slow, the bug doesn't happens? or what? :P |
| 22:23 |
sapier |
seems to be |
| 22:23 |
Exio4 |
is it a race condition? * |
| 22:30 |
VanessaE |
kahrl: also, and this is probably as obvious as the color of the sky, but with that little patch, world log-in time is drastically cut, and flipping inventory pages is like 10x faster. |
| 22:31 |
sapier |
even gdb tracepoints seem to avoid the crash |
| 22:32 |
VanessaE |
kahrl: so here's what I propose: Make that patch (or similar) into a config option, and get rid of the render-to-texture-for-items code entirely (display the real in-game objects instead) |
| 22:32 |
VanessaE |
it won't fix the root problem, but it will make for an extremely fast startup even with big textures |
| 22:33 |
VanessaE |
sapier: wait, so you are able to reproduce the crash locally now? |
| 22:33 |
VanessaE |
(outside of the above debugging steps) |
| 22:33 |
sapier |
yes I am yet it just doesn't make sense |
| 22:34 |
VanessaE |
good. :D |
| 22:34 |
sapier |
it's not even limited to the key thing I get random crashes somewhere in app |
| 22:34 |
VanessaE |
the fact that someone besides me is able to see this crash and get confused by it is a GOOD sign :D |
| 22:35 |
sapier |
no it isn't ;-) |
| 22:35 |
VanessaE |
sure it is - it means I'm not crazy or in possession of some weird, obscure broken hardware :D |
| 22:35 |
sapier |
two possible reasons ... my memory got bad (again) or a random memory corruption occurs |
| 22:36 |
|
KingsleyT joined #minetest-dev |
| 22:37 |
|
zero1922 joined #minetest-dev |
| 22:43 |
|
Taoki joined #minetest-dev |
| 22:44 |
|
Kray joined #minetest-dev |
| 23:22 |
sapier |
wow trying to allocate 109802048057794950 bytes :-) |
| 23:22 |
VanessaE |
wat!? |
| 23:23 |
sapier |
that's the reason for crash in my case |
| 23:23 |
sapier |
for some reason within a copy constructor that enormous amount of memory is thought to be the size of original element |
| 23:30 |
|
bcnjr5 joined #minetest-dev |
