Minetest logo

IRC log for #minetest-dev, 2013-11-13

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

All times shown according to UTC.

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/commi​t/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

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