IRC logs for #opendune on OFTC at 2009-12-04
⏴ go to previous day
01:05:12 *** ChanServ sets mode: +o glx_
01:05:32 *** glx is now known as Guest27
01:38:39 *** planetmaker has joined #openDune
01:38:39 *** blathijs has joined #openDune
01:38:39 *** boekabart has joined #openDune
01:38:39 *** joule.oftc.net sets mode: +ovvv glx planetmaker blathijs boekabart
01:38:39 *** TrueBrain has joined #openDune
01:38:39 *** Xaroth has joined #openDune
01:38:39 *** TinoDidriksen has joined #openDune
01:38:39 *** joule.oftc.net sets mode: +ovvv Xaroth Xaroth nsz TinoDidriksen
01:38:39 *** proyvind has joined #openDune
01:38:39 *** joule.oftc.net sets mode: +v proyvind
01:41:46 <glx> and now I need to sleep :)
07:00:21 *** ChanServ sets mode: +v Yexo
09:35:18 <Yexo> been away long enough :(
09:35:27 <TrueBrain> Yeah! WE missed you! Where have you been?
09:35:33 <TrueBrain> Currently a bit sick, but that will pass :p
09:36:12 <Yexo> busy with study/work, and eve is an addicting game once you play for a bit (I'm cured now :p)
09:36:24 <TrueBrain> EVE is only addictive for the first few weeks
09:38:38 <TrueBrain> either way, nice to have you back ;)
09:38:47 <Yexo> yeah, it's good to be back :)
09:38:57 <Yexo> just reading up on your progress on opendune.org now
09:40:00 <planetmaker> the progress's amazing :-)
09:40:06 <planetmaker> oh, and hello TrueBrain :-)
09:40:33 <TrueBrain> howdie planetmaker :)
09:40:39 <TrueBrain> progress is too slow :p Just 8% done ...
09:41:00 <planetmaker> :-P You have a funny definition of slow then
09:41:14 <planetmaker> Or you'd need to work on it fulltime and make someone pay you for it ;-)
09:41:33 <TrueBrain> now eating dry crackers .. I hate those things
09:41:47 <planetmaker> eat stroopwaffels
09:42:12 <planetmaker> then eat / drink some nice vla
09:42:19 <Yexo> that was a (slow) reaction to the dry crackers, not to the stroopwafels
09:42:40 <planetmaker> oh... only one "f" :-)
09:43:00 <TrueBrain> germans would never use one f there
09:43:18 <TrueBrain> they don't understand the linquistic concept of that
09:43:19 <Yexo> is "stroop" a word in a non-dutch language then?
09:43:24 <planetmaker> genug schwafeln über Waffeln ;-)
09:43:36 <planetmaker> Yexo, no, it's not. At least not a German one.
09:44:49 <planetmaker> if I'd have to translate, I'd call them "Sirupwaffeln" or something along that line.
09:45:01 <Yexo> you have a nice know bugs list: "random crashes", "random garbage on screen", "units disapper", "random house switches", "mouse can go crazy"
09:45:17 <Yexo> from reading that list it seem it doesn't work at all
09:45:41 <planetmaker> if you ignore the list, it works amazingly well ;-) - which doesn't make the list untrue, though
09:45:45 <Yexo> but knowing you it work a lot better then that description
09:50:01 *** ChanServ sets mode: +v Yexo_
09:52:10 <TrueBrain> Yexo: a bug list doesn't mean it happens EVERY time :)
09:53:35 <TrueBrain> in fact, most disapeared when I reverted the mouse control back to assembly :p
10:47:12 <DorpsGek> SVN: truebrain (r656) [JIT] -Add: mapped another 7 functions (crash-bins provided by glx)
10:47:55 <DorpsGek> SVN: truebrain (r657) -Update (r656): update decompiled code
11:01:23 *** Xaroth sets mode: +o TrueBrain
11:01:26 *** Xaroth sets mode: +vv tneo SmatZ
12:24:11 <TrueBrain> Xaroth: most weird call ever: LeaseWeb is calling people who are hosted at certain ASes, with the announcement one of the DCs is about to fall over, and if we want to move to leaseweb network
12:26:50 <TrueBrain> some polling, it turns out to be about 'Dataregiocentre' .. which we are NOT hosted at :s
12:35:44 <planetmaker> sounds very organized :-P
12:37:23 <TrueBrain> it sounds more like leaseweb is trying to steal customers
12:58:02 <glx> no big new stuff from my crashes.bin :)
12:58:15 <TrueBrain> did you expect anything else? :p
12:58:58 <glx> but who knows, sometimes there are calls hidden in unresolved stuff
13:18:42 <Xaroth> TrueBrain: that happens quite frequently :/
13:19:00 <Xaroth> for giants like Leaseweb it's a good way to instantly expand their customer base
13:19:16 <TrueBrain> and not accepted by dutch law :s
13:19:33 <Xaroth> technically, it's not allowed
13:19:59 <Xaroth> but if the other AS is really hitting the dirt then it's not like theyc an sue :)
13:20:06 <Xaroth> they'll have more than enough problems to worry about
13:20:13 <TrueBrain> yes, but we are hosted in EVO
13:20:19 <TrueBrain> which makes the call ... weird
13:34:22 <TrueBrain> I need to find a simple way to download all those files ....
13:35:09 <TrueBrain> glx: yes, next time please upload them to your devspace .. allows me to use scp ;)
13:35:29 <glx> needs an extra step for me :)
13:35:39 <TrueBrain> and 7 less steps for me :p
13:35:42 <glx> start winscp and grad&drop
13:43:23 <DorpsGek> SVN: truebrain (r658) -Fix: the caption got lost in decompiler updates. also bump to 'pre v0.2'
13:44:00 <DorpsGek> SVN: truebrain (r659) [JIT] -Add: mapped another 16 functions (crash-bins provided by glx)
13:44:15 <DorpsGek> SVN: truebrain (r660) -Update (r659): update decompiled code
13:44:44 <TrueBrain> I hope that is enough glx :)
13:51:13 <TrueBrain> yeah, I noticed .. was hoping you didn't care :p
13:57:31 <glx> now I use a small .bat to move it on my local www and on dev space
14:03:51 <glx> ok 3 new .bin on my dev space :)
14:05:41 <TrueBrain> bah, 2 new functions
14:05:56 <TrueBrain> glx: that makes us move the WRONG way :p
14:07:09 <glx> maybe due to some changed values
14:07:26 <TrueBrain> and the fact the return stack is not stored, therefor corrupted
14:08:26 <TrueBrain> dunno, result looks suspicious
14:09:07 <TrueBrain> it tries to jump to 0000:0000
14:09:28 <TrueBrain> so the changes you made are not possible in any world
14:09:33 <TrueBrain> in a function you can't see yet :p
14:10:46 <DorpsGek> SVN: truebrain (r661) [JIT] -Add: mapped another 13 functions (crash-bins provided by glx)
14:10:56 <DorpsGek> SVN: truebrain (r662) -Update (r661): update decompiled code
14:11:08 <TrueBrain> the code is not wrong, just ends :p
14:11:24 <glx> because invalid data passed ;)
14:29:37 <glx> I still don't get what these functions do
14:37:43 <Xaroth> sitting in car waiting for missus
15:48:24 <DorpsGek> SVN: glx (r663) -Add: named 2 more Script functions
20:14:16 *** ChanServ sets mode: +v Yexo
20:18:51 *** Alberth has joined #openDune
20:19:11 <Alberth> ha, 3rd time works :p
20:19:40 <Alberth> opendune: src/pool/unit.c:36: Unit_Get_ByMemory: Assertion `g_global->unitStartPos.csip <= address.csip && address.csip < g_global->unitStartPos.csip + sizeof(Unit) * UNIT_INDEX_MAX' failed.
20:20:21 <Alberth> stupid Fedora12 eating my core dumps :(
20:27:56 <Alberth> apparently, everybody is busy unpacking their presents :p
20:57:30 <Xaroth> which revision is that, Alberth?
20:59:41 <glx> yes very weird, unless Unit_Create doesn't return NULL when it should
21:00:06 <Xaroth> maybe memory pool depleted?
21:00:21 <Xaroth> debugging C# is a LOT different than debugging this :P
21:01:19 <glx> the order of things is Create_Unit, if not NULL, SetAction
21:01:45 <glx> but it seems unit created is after unit max
21:01:59 <glx> so I'd say Unit_Create is wrong :)
21:02:14 <Xaroth> as in, no more room in the pool to create new units, and it messes up during that?
21:02:50 <Xaroth> if so, damn, my guess what somewhere in the right area :P
21:07:26 <Alberth> the only other option is a unit -1
21:10:59 <Alberth> $1 = {s = {ip = 1, cs = 5892}, csip = 386138113}
21:10:59 <Alberth> (gdb) p g_global->unitStartPos
21:10:59 <Alberth> $2 = {s = {ip = 4, cs = 30688}, csip = 2011168772}
21:12:29 <glx> @base 10 16 [calc 386138113 - 2011168772]
21:13:12 <glx> hmm this calcul is not needed, 2 units in different CS is not normal
21:18:35 <glx> address is clearly not an unit
21:18:45 <glx> but I don't know how that can happen
21:29:55 *** ChanServ sets mode: +v Yexo
21:30:15 <Alberth> so it is wildly out of bounds rather than just one beyond the limit?
21:31:25 <glx> and it's some sort of array
21:32:34 <glx> so the only thing left is some sort of stack (emu stack) corruption
21:35:49 <Alberth> it seems fairly consistent here, one time a few days, and tonight twice
21:36:06 <glx> ,...emu_push(emu_cs); emu_push(0x241F); emu_cs = 0x1A34; emu_Unit_Create();
21:36:06 <glx> ,...emu_addw(&emu_sp, 0xC);
21:36:06 <glx> ,...emu_get_memory16(emu_ss, emu_bp, -0x2) = emu_dx;
21:36:06 <glx> ,...emu_get_memory16(emu_ss, emu_bp, -0x4) = emu_ax;
21:36:08 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, -0x2));
21:36:10 <glx> ,...emu_push(emu_get_memory16(emu_ss, emu_bp, -0x4));
21:36:12 <glx> ,...emu_push(0x245C); emu_Unit_SetAction();
21:36:34 <glx> but emu_dx is always 0x77E0 ;)
21:36:57 <glx> so something weird happens during emu_Unit_SetAction() call
21:36:58 <Alberth> add a few more checks?
21:37:47 <glx> what you get is not logical
21:40:15 <glx> something changes the values on stack or the stack pointer
21:41:20 *** ChanServ sets mode: +v Yexo
21:42:40 <glx> because emu_Unit_Create always returns emu_dx = emu_ax = 0 or emu_dx = 0x77E0, emu_ax = ...
21:44:01 <glx> we store this result in a local variable (on stack) then we pass this variable to emu_Unit_SetAction, and for some strange reason, what is taken from stack is not 77E0:...
21:44:42 <Alberth> so print retval + stackp at unit create + just before crash?
21:45:15 <Xaroth> assert on emu_dx not being 77E0 ?
21:45:35 <glx> no because 0 is valid too :)
21:47:30 <Xaroth> not being 77E0 || 0 ...
21:49:05 <Alberth> print a part of the stack just before crash?
21:50:06 <Alberth> (I am just doing random suggestions, so plz ignore me if I am talking nonsense :) )
21:53:41 <Alberth> yes, but better load the core dump again :)
21:54:32 <glx> (emu_memory + ((emu_ss) << 4) + (((emu_sp) + (0x0)) & 0xFFFF))
21:54:46 <glx> can you dump memory at that location ?
21:55:49 <Alberth> oh, it works at #1 too:
21:55:49 <Alberth> (gdb) p (emu_memory + ((emu_ss) << 4) + (((emu_sp) + (0x0)) & 0xFFFF))
21:55:49 <Alberth> $1 = (uint8 *) 0xed9640 ""
21:56:10 <Alberth> #4 0x082220d7 in Unit_Get_ByMemory (address=...) at src/pool/unit.c:36
21:56:10 <Alberth> 36 assert(g_global->unitStartPos.csip <= address.csip && address.csip < g_global->unitStartPos.csip + sizeof(Unit) * UNIT_INDEX_MAX);
21:56:10 <Alberth> (gdb) p (emu_memory + ((emu_ss) << 4) + (((emu_sp) + (0x0)) & 0xFFFF))
21:56:10 <Alberth> $2 = (uint8 *) 0x822e9c0 "t\001\367\001\b"
21:56:33 <Alberth> how to make a mem dump?
21:59:57 <glx> x /10hx (emu_memory + ((emu_ss) << 4) + (((emu_sp) + (0x0)) & 0xFFFF))
22:00:13 <glx> that should show 10 last values on stack
22:00:31 <glx> if I understand my gdb quick reference card :)
22:00:47 <Alberth> (gdb) x /10hx (emu_memory + ((emu_ss) << 4) + (((emu_sp) + (0x0)) & 0xFFFF))
22:00:47 <Alberth> 0x822e9c0 <emu_memory>: 0x0174 0x01f7 0x0008 0x0070 0x0010 0x0070 0x0018 0x0070
22:00:47 <Alberth> 0x822e9d0 <emu_memory+16>: 0x0020 0x0070
22:00:58 <Alberth> yes, I concluded that too
22:02:13 *** ChanServ sets mode: +v Yexo
22:02:52 <Alberth> (gdb) x /20hb (emu_memory + ((emu_ss) << 4) + (((emu_sp) + (0x0)) & 0xFFFF))
22:02:52 <Alberth> 0x822e9c0 <emu_memory>: 0x74 0x01 0xf7 0x01 0x08 0x00 0x70 0x00
22:02:52 <Alberth> 0x822e9c8 <emu_memory+8>: 0x10 0x00 0x70 0x00 0x18 0x00 0x70 0x00
22:02:52 <Alberth> 0x822e9d0 <emu_memory+16>: 0x20 0x00 0x70 0x00
22:02:52 <Alberth> bytes are more readable perhaps
22:04:24 <glx> anyway the stack is totally corrupted
22:05:40 <glx> big problem in libemu I'd say
22:06:03 <Alberth> yep about 0x3eee wide :)
22:07:53 <Alberth> Hmm, not much there either:
22:07:56 <Alberth> (gdb) x /10hx (emu_memory + ((0x3eee) << 4) + (((emu_sp) + (0x0)) & 0xFFFF))
22:07:56 <Alberth> 0x826d8a0 <emu_memory+257760>: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000
22:07:56 <Alberth> 0x826d8b0 <emu_memory+257776>: 0x0000 0x0000
22:08:25 <glx> emu_sp is probably wrong too
22:09:14 <Alberth> and a 64K dump is also useless.
22:10:49 <Alberth> I'll keep the exe + core dump around for the weekend or so, in case you or TB want to know some more details
22:11:04 <glx> I guess TrueBrain will have some ideas
22:11:17 * glx don't see what can happen
22:12:48 <glx> the only sure thing is something touched emu_ss/emu_sp
22:13:37 <glx> but not directly, probably through some memory overwrite
22:16:33 <Alberth> we'll wait for TrueBrain first :)
22:23:20 *** ChanServ sets mode: +v Yexo
22:25:27 *** ChanServ sets mode: +v Yexo_
continue to next day ⏵