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:21 VanessaE ah HAH! I found a good commit :D 00:21 * VanessaE keeps going. 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: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. 01:02 VanessaE any comments on this or an I just wasting my time? :P 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:25 ShadowNinja zat: https://github.com/minetest/minetest/pull/1001 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: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: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). 10:12 celeron55 cornernote requested me to remove his ban, and i did 10:18 Jordach ...explains why he's in #minetest 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 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 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: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: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 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 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: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 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: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 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 21:39 VanessaE kahrl: I'm afraid I no longer have that patch. Got it handy? :) 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: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 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