IRC logs for #opendune on OFTC at 2009-12-05
⏴ go to previous day
07:21:32 *** Alberth has joined #openDune
10:24:47 <TrueBrain> Alberth: do you have the executable and core dump for me?
10:24:52 <TrueBrain> (or a way to reproduce?)
10:29:28 <TrueBrain> Alberth: k, got them (although core.7604 was read protected :p)
10:29:38 <TrueBrain> please remove them :) (cores tend to carry much sensitive information :))
10:30:48 <Alberth> I hope they are useful
10:30:49 <TrueBrain> damn, it doesn't want to load the symbols :(
10:31:36 <TrueBrain> do you have your libemu.so for me too please :)
10:33:27 <TrueBrain> still not working :'(
10:33:35 <TrueBrain> I thought gdb was smarter than that :(
10:34:05 <TrueBrain> Error while mapping shared library sections:
10:34:06 <TrueBrain> 9�u��������T$�E�: No such file or directory.
10:38:55 <SmatZ> nope, I rarely use core dumps
10:38:59 <SmatZ> I have them disabled...
10:39:18 <TrueBrain> most OSes have that by default these days
10:39:25 <TrueBrain> so Alberth has to be my gdb :p
10:39:44 <TrueBrain> Alberth: is this the same core dump as you used yesterday?
10:39:50 <TrueBrain> as the pointers do not match
10:40:31 <TrueBrain> #0 0x00e21424 in __kernel_vsyscall ()
10:40:33 <TrueBrain> #1 0x0095ba81 in ?? ()
10:40:34 <TrueBrain> #2 0x00aa1ff4 in ?? ()
10:40:36 <TrueBrain> #3 0xbfdfde68 in ?? ()
10:41:01 <TrueBrain> I can understand it can't name the first btw, it is in libc of course :p
10:41:18 <Alberth> #0 0x00e21424 in __kernel_vsyscall ()
10:41:19 <Alberth> #1 0x0095ba81 in raise () from /lib/libc.so.6
10:41:33 <TrueBrain> yes, but #2 differs A LOT :p
10:41:51 <Alberth> #2 0x0095d34a in abort () from /lib/libc.so.6
10:42:03 <TrueBrain> but okay .. might be the libc.so.6 mismatch or something ..
10:42:19 <Alberth> most likely, I upgraded to Fedora 12 less than a week ago
10:45:27 <TrueBrain> rest assure my libc.so is most likely newer :p
10:46:07 <TrueBrain> k, Alberth, frame 5, variable 'ucsip' and 'action', what do they contain?
10:46:14 <TrueBrain> and what is ss/sp in frame 5
10:47:10 <Alberth> #5 0x0821eca4 in emu_Unit_SetAction () at src/emu_unit.c:266
10:47:10 <Alberth> 266 u = Unit_Get_ByMemory(ucsip);
10:47:10 <Alberth> $1 = <value optimized out>
10:47:11 <Alberth> $2 = <value optimized out>
10:47:13 <Alberth> No symbol "ss" in current context.
10:47:35 <TrueBrain> and why was there any form of optimization :(
10:47:47 <TrueBrain> k, at least stackpointers are not corrupted
10:48:31 <TrueBrain> x /10hb (emu_memory + (emu_ss << 4) + emu_sp)
10:49:02 <Alberth> somebody added -O1 in the makefile :)
10:49:10 <TrueBrain> yeah... it still is required :'(
10:49:26 <Alberth> (gdb) x /10hb (emu_memory + (emu_ss << 4) + emu_sp)
10:49:26 <Alberth> 0x826e73a <emu_memory+261498>: 1 0 4 23 0 0 1 0
10:49:26 <Alberth> 0x826e742 <emu_memory+261506>: 4 23
10:50:10 <TrueBrain> maybe more readable in this case :p
10:50:30 <Alberth> (gdb) x /10hx (emu_memory + (emu_ss << 4) + emu_sp)
10:50:31 <Alberth> 0x826e73a <emu_memory+261498>: 0x0001 0x1704 0x0000 0x0001 0x1704 0x0f0c 0x0935 0x0642
10:50:31 <Alberth> 0x826e74a <emu_memory+261514>: 0x0216 0x7900
10:51:20 <TrueBrain> x /10hx (emu_memory + (emu_ss << 4) + emu_sp - 4)
10:51:32 <Alberth> (gdb) x /10hx (emu_memory + (emu_ss << 4) + emu_sp - 4)
10:51:32 <Alberth> 0x826e736 <emu_memory+261494>: 0x245c 0x176c 0x0001 0x1704 0x0000 0x0001 0x1704 0x0f0c
10:51:32 <Alberth> 0x826e746 <emu_memory+261510>: 0x0935 0x0642
10:51:48 <TrueBrain> that at least is correct
10:52:15 <Alberth> so it crashes quite quickly
10:52:53 <TrueBrain> frame 6, emu_sp and emu_bp
10:53:22 <Alberth> #6 0x080e40de in f__176C_23CC_000B_4119 () at decompiled/cs__176C.c:3786
10:53:22 <Alberth> 3786 emu_push(0x245C); emu_Unit_SetAction();
10:53:42 <TrueBrain> also within acceptable range ..
10:54:53 <Alberth> grabbing some lunch, will be right back
10:55:44 <TrueBrain> x /10hx (emu_memory + (emu_ss << 4) + emu_bp)
10:55:48 <TrueBrain> enjoy your lunch :)
10:55:56 <TrueBrain> x /10hx (emu_memory + (emu_ss << 4) + emu_bp - 4)
10:56:33 <TrueBrain> and emu_dx in frame 6
10:57:44 <Alberth> (gdb) x /10hx (emu_memory + (emu_ss << 4) + emu_bp)
10:57:44 <Alberth> 0x826e744 <emu_memory+261508>: 0x0f0c 0x0935 0x0642 0x0216 0x7900 0x1900 0x2b00 0x0003
10:57:44 <Alberth> 0x826e754 <emu_memory+261524>: 0x1b00 0x2d00
10:57:44 <Alberth> (gdb) x /10hx (emu_memory + (emu_ss << 4) + emu_bp - 4)
10:57:44 <Alberth> 0x826e740 <emu_memory+261504>: 0x0001 0x1704 0x0f0c 0x0935 0x0642 0x0216 0x7900 0x1900
10:57:45 <Alberth> 0x826e750 <emu_memory+261520>: 0x2b00 0x0003
10:57:47 <Alberth> No symbol "emu_dx" in current context.
10:57:57 <TrueBrain> eeuhh ... yeah, emu_dx is hidden
10:58:03 <TrueBrain> but nevermind, I know what is going wrong ...
10:58:03 <Alberth> didn't change frame, so that should be ok
10:58:19 <Xaroth> to me, that makes absolutely no sense
10:58:55 <Alberth> what, that TB can understand stack data ?
10:59:16 <Xaroth> more the opposite for me :P
10:59:41 <Xaroth> and I had kinda guessed TB knows stuff like that.. I mean.. one doesn't create a decompiler without any knowledge about stuff like that..
11:00:26 <Alberth> if you do assembly language long enough you can read a program from the byte values :)
11:01:05 <Xaroth> that goes even beyond my geekness :P
11:03:14 <Alberth> stacks are relatively easy. TB has a good idea of valid pointer values, and he knows what goes on the stack with each call, so once he has a starting point he knows which value goes in what register
11:03:42 <TrueBrain> well, this is even worse
11:03:47 <TrueBrain> anyone could have found this problem
11:03:56 <TrueBrain> somehow I just had this weird moment where I realised it :p
11:05:33 <TrueBrain> for some reason the code assumed emu_ax and emu_dx were not used as a shared variable ;)
11:05:47 <TrueBrain> so when Unit_Create calls a emu_ function (and it does that a lot), it assumed dx/ax was unchanged
11:05:54 <TrueBrain> which of course is the biggest bullshit you can get
11:06:25 <TrueBrain> funny enoguh, this problem only exists when things fail
11:07:22 <DorpsGek> SVN: truebrain (r664) -Fix: emu_ax/emu_dx are used as shared variables all over the place. Don't expect them to be unchanged when calling a partial converted function (tnx Alberth for your gdb output; we couldn't have find it without it :))
11:07:39 <TrueBrain> Alberth: update, and please tell me in a week it didn't crash :p
11:08:00 <TrueBrain> this was such a stupid mistake .... :p
11:09:21 <Alberth> I shall refrain from playing OpenDune for a week so I can tell you the great news :p
11:09:25 <TrueBrain> I now just wonder why a script wants to create a Tank for ...
11:09:27 <TrueBrain> Alberth: ghehehehehe :p
11:11:16 <TrueBrain> ah, no, this function makes from a squad a single soldier :)
11:11:17 <Alberth> I don't play a lot, so it can be weeks easily.
11:12:14 <Alberth> Some battle was going on, mostly atreides troops walking into my turret fire
11:12:48 <TrueBrain> yeah ... I think this is a bit stupid .. when a squad goes to a single unit, it creates a new unit, instead of modifying the current
11:13:05 <Alberth> Although I may also be losing some iirc
11:13:26 <TrueBrain> and if I read this correctly, the unit is not even destroyed
11:13:38 <TrueBrain> so at that instance there are 2 of them :s
11:14:06 <TrueBrain> but I can read this function all wrong of course :)
11:14:23 <TrueBrain> just one way to find out!
11:14:40 <Alberth> that would be fun, shoot the enemy and get two :)
11:16:22 <TrueBrain> reading a function for the first time is always guessing ;)
11:16:39 <TrueBrain> that makes it fun :)
11:17:02 <TrueBrain> Xaroth: btw, such stack dumps do make sense to you too if you would have the code next to it :)
11:17:16 <TrueBrain> as it is one-on-one what the code says
11:17:21 <Xaroth> that might be the issue then :P
11:17:26 <TrueBrain> bp-04 is 0x0001, bp-02 is 0x1704, ...
11:17:28 <Xaroth> seeing i have the missus next to me :)
11:17:37 <TrueBrain> boop-destraction, I get it
11:18:19 <TrueBrain> k, at least I was right about the function of this routine
11:19:04 <TrueBrain> still it makes NO SENSE at all :(
11:19:38 <Alberth> perhaps the higher level function removes the original unit afterwards
11:19:48 <TrueBrain> a script in this case
11:19:53 <TrueBrain> still .. why so complex?
11:20:16 <TrueBrain> another 'fun' fact is that it seems to happen at 'random' hp
11:21:56 <TrueBrain> Xaroth: what does 'f__0F3F_01A1_0018_9631' do? (Tile function :p)
11:24:32 <Xaroth> if it's not named I probably have had no clue yet :P
11:24:48 <Xaroth> unless it's the one i tried to mock-up ... in which case I really have no clue
11:24:54 <Alberth> hmm, loading a file triggered a non-compiled function
11:24:55 <DorpsGek> SVN: truebrain (r665) -Move: moved script files to their own subdir
11:25:05 <Alberth> Program Termination: jumped to 426D:0100, which is not decompiled.
11:25:05 <Alberth> The jump was triggered at decompiled/cs__B4C4.c:185
11:25:05 <Alberth> The jump appears to originate from B4C4:0100.
11:25:36 <Alberth> is that due to a corrupted state?
11:25:48 <TrueBrain> I would like that crash.bin :)
11:26:25 <Alberth> hmm, unlikely, before the update I could play with it
11:27:10 <TrueBrain> but this fixes a few nasty errors, so ...
11:28:18 <Alberth> Program Termination: jumped to 421F:0100, which is not decompiled.
11:28:18 <Alberth> The jump was triggered at decompiled/cs__B4C4.c:185
11:28:18 <Alberth> The jump appears to originate from B4C4:0100.
11:28:18 <Alberth> from the same address
11:29:20 <DorpsGek> SVN: truebrain (r666) -Fix (r665): compile before commit
11:29:44 <Alberth> make a 'make commit' :)
11:31:39 <DorpsGek> SVN: truebrain (r667) [JIT] -Fix: one more problem found by Alberth
11:31:47 <DorpsGek> SVN: truebrain (r668) -Update (r667): update decompiled code
11:33:01 <TrueBrain> whoho, tcc builds work like a charm :)
11:34:25 <TrueBrain> Alberth: that is one of the positive things of flaws, you find other flaws too, when fixing them ;)
11:35:02 <TrueBrain> we still have 833 unresolved entries, of which 31 are due to Terminate
11:35:22 <TrueBrain> which leaves about 800 valid unresolved jumps ... one way or the other, they will be called :)
11:48:52 <TrueBrain> Mission lost seems to no longer work :p
11:48:57 <TrueBrain> I just lost my CY .. and all my units ..
11:52:22 <DorpsGek> SVN: truebrain (r669) [JIT] -Add: mapped another 3 functions (crash-bins provided by TrueBrain)
11:52:32 <DorpsGek> SVN: truebrain (r670) -Update (r669): update decompiled code
11:53:21 <TrueBrain> still no clue what the function does
11:53:26 <TrueBrain> oh well, time to do a bit of shopping
12:36:41 <TrueBrain> btw, Alberth, is reinforcement working correctly?
12:36:46 <TrueBrain> or are you not using the updated scenario.pak?
12:38:09 <Alberth> no, I use the old scenario's
12:38:17 <Alberth> that's difficult enough :p
12:39:30 <Alberth> all that scrolling and positioning the main display makes it cumbersome to fight
13:39:44 <Alberth> hmm, you cannot place a completely built structure when repairing the CY
13:40:41 <TrueBrain> the hp of a new structure depends on the fact if it has slabs below it or not
13:40:45 <TrueBrain> not the state of the CY
13:42:21 <Alberth> no, finished making a new structure in the CY, then click 'repair' of the CY. Placing the new structure stops repairing
13:43:18 <TrueBrain> so .. you could place a structure, you pressed Repair, clicked Place, placed the structure, and then the repairing stopped
13:43:40 <TrueBrain> for the same reason you can't repair and build
13:43:42 <TrueBrain> it is one of the two
13:44:50 <Alberth> it feels like differently though, since placing does not cost time
13:45:28 <TrueBrain> Alberth: write it down as suggestion on the forum ;)
13:47:14 <glx> any news about Alberth's crash ?
13:49:09 <glx> I should have think about it
13:49:10 <TrueBrain> glx: a nice one for you: script f__176C_23CC_000B_4119 seems to be called for Squad Soldier (not for the rocket variant); it creates a new unit (a single infantry) at almost the same place as the old one when it gets below a random hp value .. I don't get why it doesn't alter the unit, or why the rocket squad doesn't follow the same :s
13:49:19 <TrueBrain> glx: we all should have :p It was a bit silly and stupid .. :p
13:49:42 <glx> yes 23CC seems to be soldier after vehicle destruction
13:49:51 <TrueBrain> oh, for a random vehicle
13:49:55 <TrueBrain> that makes a bit more sense ..
13:50:15 <TrueBrain> it also gets assigned random health
13:50:31 <TrueBrain> k .. then it makes sense ;)
13:50:45 <Alberth> ah, that explains the random soldiers at the battle field :)
13:50:59 <glx> same happens for structures too
13:51:16 <glx> but there are 2 soldiers there usually :)
13:52:40 <TrueBrain> then I also get why it creates a new one for it
13:53:18 <glx> so in gdb emu_ss and emu_sp were useless ?
13:53:26 <TrueBrain> no, they were working and valid
13:53:39 <TrueBrain> just you ened to switch to the right frame when you look at them :p
13:55:17 <TrueBrain> but yeah, this bug explained a few problems we encountered :p
13:58:11 <glx> I like the latest version of generate :)
13:58:24 <TrueBrain> it took care of the scripts correct?
13:58:25 <glx> nice project file with subdirs
13:58:29 <TrueBrain> I believe I forgot one update on it ..
13:58:57 <DorpsGek> SVN: truebrain (r671) -Fix (r666): forgot to update MSVC project files
14:01:17 <TrueBrain> you have to come pass them at least once ...
14:05:00 <Xaroth> as long as I can commit 1337.
14:05:09 <Xaroth> or 1338, to be anti1337 :P
14:05:18 <TrueBrain> I prereserved a few revisions
14:14:32 <TrueBrain> was just considering that yes :p
14:14:39 <TrueBrain> the one in the 23CC function is rand() % 256
14:14:45 <TrueBrain> the other is rand() % 65536 I believe
14:16:10 <TrueBrain> yeah, it is a kind of important difference :) 2 completely different random functions too :)
14:16:20 <TrueBrain> one seems a simplified one, I doubt the entropy is anywhere near 0
14:16:28 <TrueBrain> the other is more complex, and more solid, from what I can tell
14:17:09 <TrueBrain> you are going to name him glx? Also the 176C:23CC function?
14:17:38 <TrueBrain> k, then I continue naming other functions
14:17:49 <TrueBrain> I decided to name functions for now, it turns out to be so much more useful :)
14:18:15 <glx> yes naming is useful but sometimes it's not easy
14:18:26 <TrueBrain> nope; but after naming, the transforming to C is much easier
14:18:37 <TrueBrain> on the other hand, from time to time transformingto C gives the name of many functions :p
14:18:56 <glx> yes because then you understand what it does
14:25:58 <TrueBrain> f__0642_0AD2_002A_8B98 is .. suprising
14:26:04 <glx> ,...emu_push(emu_cs); emu_push(0x01DB); emu_cs = 0x2BB4; emu_Tools_Random_256();
14:26:04 <glx> ,...emu_andw(&emu_ax, 0xFF);
14:26:20 <TrueBrain> that is what you get by casting and not optimizing ;)
14:26:39 <TrueBrain> uint8 var = emu_Tools_Random_256(), when that function returns a uint16 :)
14:28:22 <TrueBrain> glx: you named 353F:6D8D .. you remember in what context?
14:29:08 <TrueBrain> all related to cs__1DD7
14:29:54 <TrueBrain> as all 1DD7 functions seem to do well .. nothing :p
14:30:12 <TrueBrain> most contain dynamic loaders
14:30:19 <TrueBrain> but most all jumps to the end of the function ASAP :p
14:31:00 <glx> hmm yes should be sound related
14:31:17 <TrueBrain> 48 unresolved in that cs alone :p
14:31:31 <TrueBrain> so f__0642_0AD2_002A_8B98() is something like, continue sound
14:31:39 <TrueBrain> no .. initialize sound
14:31:45 <TrueBrain> DUNEINIT is called (string-wise)
14:32:03 <glx> f__1DD7_039B_0008_D3BD sets 8D6D and is called with 98E2..98E4
14:32:43 <TrueBrain> so yes, sound stuff
14:33:20 <TrueBrain> so I guess DUNEINIT is a sound
14:40:50 <glx> oh nice, if the destroyed unit is deviated, the new one is deviated too :)
14:41:38 <TrueBrain> hmm .. in the middle of a song I lost my optic output
14:42:23 <TrueBrain> but only for flac playback
14:42:25 <TrueBrain> mp3 and DTS work fine
14:43:06 <TrueBrain> hmm .. more exact, only for a certain directory :p
14:43:36 <TrueBrain> but it does work when I do a playback over other interfaces ...
14:43:45 <TrueBrain> even indirect reroute to my optic out ...
14:46:09 <TrueBrain> sometimes I get what a function does, but I have no idea when it is called ;)
14:47:10 <glx> +176C:23CC:000B:4119,...emu_Script_Unit_RandomSoldier,...# (script_csip) randomly generates a new soldier around currentUnit location
14:48:04 <TrueBrain> or maybe: MakeRandomSoldier
14:48:53 <glx> I know it creates a new one if rand() < unitinfo->variable_E
14:49:43 <TrueBrain> make sure to document that ;)
14:49:47 <TrueBrain> (the variable_0E thing :p)
14:49:58 <glx> too bad only build.emx is the only one fully decoded
14:50:20 <TrueBrain> makes the job for units more fun :)
14:50:41 <TrueBrain> btw, even if documentation at variable_0E starts with ??, that is fine by me, if at least it contains a pointer to the possible value :p
14:53:20 <TrueBrain> how do you place something with the keyboard ...
14:53:30 <TrueBrain> it seems decompiled, but I can't dind the key for it :p
14:55:29 <glx> space or enter, nut the doc is not clear
14:56:58 <glx> and only when there's no mouse it seems
14:57:53 <TrueBrain> ah, that is possible
14:58:05 <TrueBrain> @base 10 16 [calc 0x8d09 - 0x8CFD]
15:00:13 <TrueBrain> biggest maps are 62x62, but the smaller ones are 32x32
15:01:45 <TrueBrain> and there seems to be code fro another map size
15:13:33 <TrueBrain> if I read this code correctly, the data is: for type 0, the top-left is at (1,1) and the size is (62,62)
15:13:42 <TrueBrain> for type 1, top-left is (16, 16) and size is (32,32)
15:13:50 <TrueBrain> for type 2, top-left is (21, 21) and size is (21, 21)
15:14:27 <TrueBrain> visible display is always 14x14 tiles
15:15:46 <Xaroth> [@glx]: too bad only build.emx is the only one fully decoded << yeh, would make implementing LUA so much more easy :)
15:15:57 <TrueBrain> hmm .. viewport size is weird ..
15:16:02 <TrueBrain> oh .. hmm .. I should learn to read :)
15:16:10 <TrueBrain> @calc 0x10000 - 0xFFF6
15:16:11 <TrueBrain> @calc 0x10000 - 0xFFF1
15:17:17 <DorpsGek> SVN: glx (r672) -Add: figured out some Unit variables
15:17:41 <DorpsGek> SVN: glx (r673) -Add: named 2 more functions
15:20:17 <TrueBrain> unknown is written with an n on the end glx ;)
15:20:33 <TrueBrain> and ther eis no shame in writing 'argument' ;)
15:21:36 <DorpsGek> SVN: glx (r674) -Fix (r672): typos ;)
16:03:18 <TrueBrain> hmm .. I have a variable 0x35 access in StructureInfo ... 2 byte access
16:04:14 <TrueBrain> oh, wait, 0xC offset
16:04:24 <TrueBrain> @base 10 16 [calc 0x44 - 0xC]
16:04:39 <TrueBrain> @base 10 16 [calc 0x35 - 0xA]
16:18:53 <DorpsGek> SVN: truebrain (r675) -Add: figred out a few more variables (mostly related to viewport and selection)
16:19:40 <DorpsGek> SVN: truebrain (r676) -Add: named a few functions (mostly related to selection)
16:42:49 <DorpsGek> SVN: truebrain (r677) -Fix: typo in comment
16:52:38 <DorpsGek> SVN: truebrain (r678) [JIT] -Add: mapped another function (crash-bins provided by TrueBrain)
17:02:23 <DorpsGek> SVN: truebrain (r679) -Update (r678): update decompiled code
continue to next day ⏵