IRC logs for #opendune on OFTC at 2010-05-02
⏴ go to previous day
06:07:01 *** ChanServ sets mode: +o TrueBrain
06:07:01 *** ChanServ sets mode: +v Xaroth|Work
12:52:21 <glx> hmm maybe "The jump was triggered at decompiled/cs__B4CD.c:69" crashes are valid indeed (because they are quite frequent)
12:53:11 <TrueBrain> maybe we forgot a cs change again? :)
12:53:45 <glx> clearly looks like it, but I don't see how it can happen (I've written a possible scenario yesterday)
12:57:53 <glx> but how are the chances for the overlay to be reloaded ?
13:01:55 <glx> so the only fix I see is to convert the function
13:02:11 <TrueBrain> overlays shouldmn't be an issue
13:02:14 <TrueBrain> as they are reloaded on return
13:02:15 <glx> so it doesn't rely on cs for the switch
13:02:20 <TrueBrain> but I havent looked at the code yet
13:03:10 <glx> but no reload on "internal" call return
13:03:40 <TrueBrain> copy/paste? I don't really get what you mean :p
13:04:19 <glx> B4CD:0000 calls B4CD:1B5B (normal call without overlay() stuff)
13:04:38 <glx> if overlay is reloaded in 1B5B, emu_cs can change
13:05:34 <glx> but on return to 0000, emu_cs is restored to what it was before the call even if the code is at another place
13:06:13 <TrueBrain> it is restored to the value on the stack
13:06:17 <TrueBrain> and the overlay changes this too
13:06:22 <TrueBrain> (how else could it work in the first palce :p)
13:06:40 <glx> it doesn't change all values on the stack
13:06:53 <glx> only for 0F3F calls in 1B5B
13:07:05 <TrueBrain> I really don't follow what you try to say :)
13:07:51 <glx> in B4CD:0000 there is push(cs); push(ip); call B4CD:1B5B
13:08:26 <glx> in B4CD:1B5B, there are calls to 0F3F function and overlays()
13:09:47 <glx> so overlay stuff is ok in B4CD:1B5B I think, but the return CS:IP of the first call (0000->1B5B) is not updated I think
13:10:16 <TrueBrain> the overlay is near perfect, it restores all cs correctly
13:10:21 <TrueBrain> otherwise it could never ever work :)
13:10:49 <glx> overlay stuff checks all the stack?
13:10:52 <TrueBrain> so unless we make a copy of the cs and recover that, or forget to set the cs, things break
13:11:07 <TrueBrain> yes, it walks all function-calls to see if the cs:ip matches
13:11:10 <TrueBrain> and corrects where needed
13:11:25 <glx> ,...emu_push(0x0011); f__B4CD_1B5B_0011_08DE();
13:11:42 <glx> so this call may need overlay() addition just to be sure
13:12:01 <TrueBrain> all calls to B4CD_0000 ensure it is loaded
13:12:12 <TrueBrain> and it can't be unloaded in between
13:13:03 <TrueBrain> no, all calls that might unload it, have a line after them that reloads it
13:13:17 <TrueBrain> 0F3F for example never unloads it
13:13:28 <TrueBrain> if (emu_cs == 0x34CD) { overlay(0x34CD, 1); }
13:13:36 <TrueBrain> it makes 100% sure the B4CD overlay is loaded
13:13:47 <glx> I know, but emu_cs can still be wrong on return to 0011
13:14:10 <TrueBrain> the stack entries are changed by the overlay manager
13:14:16 <TrueBrain> it will never leave a reference to an invalid overlay
13:14:23 <TrueBrain> no, something corrupts the stack compeltely
13:14:32 <TrueBrain> as both the CS but also the IP is garbage
13:15:09 <TrueBrain> we never set the IP to 13EB, so it can never have that value
13:15:17 <glx> IP is "right" it's what is at emu_get_memory16(emu_cs, emu_bx, 0x9D)
13:15:49 <TrueBrain> well ... how often does this happen, and how to reproduce?
13:16:10 <glx> dunno, but tneo had it many times already
13:16:47 <TrueBrain> but there is a good chance we fucked up some C-ification, as we did before with the cs stuff :p
13:19:27 <TrueBrain> dunno .... is hard to trace such things
13:19:46 <TrueBrain> possible the overlay manager starts to fail in calls we make to the emu_ part from C-ified code
13:19:51 <TrueBrain> but then it should happen much more often
13:21:45 <glx> well in 03F3 we pop CS:IP in the begining and return value is written to stack, but I see nothing wrong there
13:22:13 <TrueBrain> the 3F3 stuff is fine, very small functions with no underlying calls
13:22:17 <TrueBrain> but maybe others fuck it up ... dunno
13:25:37 <TrueBrain> I do know I walked the logic when we started this, and concluded it was safe
13:26:05 <TrueBrain> it would help to have a backtrace on such errors
13:27:41 <glx> 11 00 d2 41 9a 02 9a 02 84 0e a6 06 1a 15 9a 02 00 00 00 00
13:27:41 <glx> B4CD:1B5B arg06 SI BP B4CD:0000 arg06 arg08 arg0A
13:28:37 <TrueBrain> what am I looking at?
13:30:23 <glx> B4CD:0000 is called from 1A15:06A6 with 029A 0000 0000
13:30:47 <glx> the BP and SI are pushed (as often ;) )
13:31:07 <glx> then B4CD:1B5B is called with 029A
13:31:31 <glx> and it returns to 41D2:0011
13:31:44 <glx> problem: 41D2 is now wrong
13:33:07 <glx> or the overlay has been unloaded
13:33:37 <TrueBrain> overlays are in reality never unloaded
13:34:08 <TrueBrain> others can be loaded over them, but that is it :)
13:34:47 <TrueBrain> f__B4CD_1B5B_0011_08DE should never be touching overlays
13:35:15 <TrueBrain> f__B4CD_0000_0011_95D0 was called from 1A15 you said?
13:35:37 <glx> that's what I get from the stack
13:35:46 <TrueBrain> we converted 1A15 completely already
13:37:02 <TrueBrain> that function call ensures the overlay gets loaded
13:37:35 <glx> 01 00 8f 1b d2 41 06 00 00 00 9a 02 06 00 14 00 0a 00 66 0e <-- latest 0F3F call
13:38:05 <TrueBrain> 965 emu_cs usages left ..
13:38:09 <glx> with BP, 3 local vars, SI, DI, arg06 CS IP
13:38:22 <TrueBrain> but just a handful in overlays
13:39:26 <glx> hmm I copied too much (the first 01 00 should not be there)
13:39:28 <TrueBrain> can you dump 34CD:0000 for me .. say .. 32 bytes or something?
13:39:46 <glx> so CS seems to not change
13:39:58 <TrueBrain> the cs should not change
13:40:04 <TrueBrain> no function causes an overlay reload
13:40:36 <glx> and it doesn't change indeed -> 412D inside 1B5B and 0000
13:40:45 <glx> so something else is wrong
13:41:12 <TrueBrain> (I assume you loaded the memory dump via MSVC and can now look at everything?)
13:41:21 <TrueBrain> or just using a hexdump to walk through the memroy dump?
13:42:14 <TrueBrain> ah :) That I can do myself :p
13:42:18 <TrueBrain> just calculating the offset is a btich ...
13:42:23 <TrueBrain> 5 bytes and 20 words ...
13:42:26 <TrueBrain> so .. 45 byte offset
13:42:58 <glx> that's how I go to current stack ;)
13:44:51 <TrueBrain> the overlay is loaded at 41D2
13:47:48 <TrueBrain> if I remember correctly, there was a small header beforeoverlays
13:47:51 <TrueBrain> but can't find it back
13:48:21 <TrueBrain> that is because it is not here
13:48:31 <TrueBrain> there is a small snippit which says which overlay it is
13:48:46 <TrueBrain> for example at 0x3FF3B
13:48:53 <TrueBrain> 34F2 is loaded there
13:48:56 <glx> and that can explain why it reads 13EB at cs:9D
13:49:34 <TrueBrain> but the question is, why the overlay never detected it overwrote another overlay, nor reloaded it
13:50:48 <TrueBrain> only two big overlays are loaded
13:51:13 <TrueBrain> and thisone at 0x41D2
13:51:42 <TrueBrain> a few smaller ones .. one at 0x4139
13:52:36 <TrueBrain> but okay, we had these issues from the start ... so either there is a bug in libemu, causing minor errors in math
13:52:45 <TrueBrain> or my method of handling overlays is fucked
13:52:48 <TrueBrain> or something is just weird
13:53:17 <glx> 41D2:0000 looks wrong in the dump anyway (starts with 0c 9a 69 01 6c ...) which doesn't look like the function it should be
13:53:34 <TrueBrain> but I agree with you that it always seems to happen in B4CD
13:54:23 <TrueBrain> although thatone is vastly different
13:54:48 <glx> yup, but too much similarities to be random ;)
13:55:23 <glx> missing line in this report ;)
13:55:24 <TrueBrain> point here is, it happens from r1, so I doubt it is due to C-ification
13:55:30 <TrueBrain> yeah, that is besides the point :p
13:55:39 <TrueBrain> look in the crash.bin if you want to know :p
14:05:18 <glx> cd 3f 00 00 00 9d 00 00 61 1d 28 01 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <-- 34CD:0000
14:05:42 <TrueBrain> a bit lower, you will see the jumps to 420A
14:07:27 <glx> cd 3f 00 00 00 b9 04 00 61 1d 28 01 23 00 00 00 0a 42 da 34 00 00 00 00 cb 04 04 00 83 34 00 00 <-- 34CD:0000 in #29
14:07:38 <TrueBrain> that is how the overlay works :)
14:08:06 <glx> cd 3f 00 00 00 b9 04 00 61 1d 28 01 23 00 00 00 d2 41 da 34 00 00 00 00 cb 04 04 01 8b 34 00 00 <-- and in #39
14:08:24 <TrueBrain> now start a normal game, add a breakpoint, and see what it is then?
14:11:21 <glx> cd 3f 00 00 00 b9 04 00 61 1d 28 01 23 00 00 00 f1 3f da 34 00 00 00 00 cb 04 00 00 00 00 00 00 <-- first breakpoint in B4CD:0000
14:11:43 <glx> so overlay loaded at 3FF1 if I read correctly
14:11:46 <TrueBrain> hmm .. wait .. CB 04 .. hmm ..
14:11:54 <TrueBrain> or anyway, the last time it was
14:12:44 <TrueBrain> yes, and of crash.bins :p
14:12:53 <TrueBrain> that I used to identify if an overlay is loaded
14:13:02 <glx> ea c4 04 f1 3f ea 66 05 f1 3f ea 94 01 f1 3f ea 7f 01 f1 3f ea 50 05 f1 3f ea 08 04 f1 3f ea 3b <-- current
14:13:25 <glx> ea c4 04 d2 41 ea 66 05 d2 41 ea 94 01 d2 41 ea 7f 01 d2 41 ea 50 05 d2 41 ea 08 04 d2 41 ea 3b <-- #39
14:13:32 <TrueBrain> yeah, EA is a far jump
14:13:58 <glx> ea c4 04 0a 42 ea 66 05 0a 42 ea 94 01 0a 42 ea 7f 01 0a 42 ea 50 05 0a 42 ea 08 04 0a 42 ea 3b <-- #29
14:14:01 <TrueBrain> so the overlay manager really indicates the overlay is still loaded
14:14:14 <TrueBrain> so I am back again to my thinking it is a process that overwrites random memory
14:14:21 <TrueBrain> which I suspect from day 1 is the issue ..
14:16:02 <glx> now the problem is to find what overwrites the memory
14:16:16 <TrueBrain> something just before B4CD is called, I suspect :p
14:21:05 <glx> cd 3f 00 00 00 b9 04 00 61 1d 28 01 23 00 00 00 1f 42 da 34 d2 f1 10 00 03 0c 00 00 00 00 00 00 <-- before call in 151A, I guess it says overlay is not loaded
14:24:20 <glx> ha it is still loaded indeed because there's EA at 34CD:20 (if I understand it)
14:29:32 *** ChanServ sets mode: +o glx_
14:30:12 <glx_> reboot is fast I have not timeout
14:30:42 *** glx is now known as Guest57
14:40:43 <TrueBrain> CD 3F is interrupt call to 3F, where the overlay manager is
14:40:49 <TrueBrain> EA blabla is a far jump to the loaded code
14:40:57 <TrueBrain> after int 3F, stuff is rewritten to EA and co
14:41:02 <TrueBrain> so next calls are much faster
14:57:14 <TrueBrain> I hate windows .. it fails to scan our local LAN for other users ....
15:16:27 <glx> hmm ntfs errors in event log, let's check the disks
15:44:00 <tneo> the freezes are utterly annoying :-/
15:55:56 <TrueBrain> when they happen, CTRL+C, brings you in gdb
15:56:01 <TrueBrain> and send us the backtrace
15:56:24 <TrueBrain> or did I add a CTRL+C handler ..hmm .. can't remember :p
15:58:07 <TrueBrain> I believe you have to do the CTRL+C in gdb .. not sure :p
15:58:19 <tneo> i'll found out soon enough :-P
16:21:35 <TrueBrain> next time, please resume a bit, and break again
16:21:41 <TrueBrain> (you resume by pressing 'r' I believe)
16:22:12 <TrueBrain> see if it stays in the same circle
16:24:36 <tneo> you should tell me those things upfront ;-) :-P
16:25:11 <TrueBrain> in such freeze, does the mouse still move?
16:25:35 <tneo> mostly yes, but no response
16:26:23 <TrueBrain> k, I will play a long game myself, see if I can get it local here too
16:31:53 <TrueBrain> tneo: is there anything special you are doing when it hangs?
16:32:35 <TrueBrain> something you click
16:33:07 <tneo> that is random, happens while scrolling, attacking or building
16:35:57 <TrueBrain> finally worth it to make slabs below a construction :)
16:37:27 <TrueBrain> when on slabs, no degrate
16:48:12 <TrueBrain> so far the game still plays, but I am not really playing ... :p
18:57:11 <tneo> initial units have changed in level 9 atreides, don't have any launchers 2 sonic tanks and 4 siege tankes
19:36:44 <tneo> TrueBrain, it will not resume after a freeze
19:37:03 <TrueBrain> then tell me if the backtrace is identical to the last one or not :)
19:38:26 <TrueBrain> you could have attached it to the other one?
19:38:48 <tneo> it's good for bug report count :-P
19:42:26 <TrueBrain> both traces look perfectly valid
19:42:30 <TrueBrain> so not really helping
19:42:37 <TrueBrain> it looks like Dune2 itself comes in an infinite loop of some kind
19:42:46 <TrueBrain> (mouse movement is done via interrupt, which always hits)
19:44:50 <tneo> i now payed attention to it :-)
19:46:08 <tneo> i now see spies on radar
19:46:27 <tneo> can't recall to have had that in the past
19:48:00 <TrueBrain> and they do show up in 1.07
19:57:21 <glx> looks like I have a RAM problem indeed
19:59:24 <glx> that explains the blue screen
19:59:40 <TrueBrain> lucky for you, memory is cheap these days :)
20:00:22 <glx> I need to find which one is dead
20:00:31 <TrueBrain> or what is it called
20:00:40 <TrueBrain> will tell you in high detail which bank, which schip, which array
20:01:15 <glx> I'm running memtest (and it yells rapidely)
20:01:32 <TrueBrain> it will also tell you if it is your controller or not :p
20:02:03 <TrueBrain> there is a chipset in between :)
20:02:21 <glx> amd has integrated controller
20:02:36 <TrueBrain> either way ... memtest will tell you :)
20:31:03 <tneo> end titles keep on going and repeating though
20:36:01 <glx> ok removed 2GB (2*1), no error so far (so I have some info :) )
20:58:51 <TrueBrain> tneo: most likely timing issues with voice/audio :p
20:59:10 <TrueBrain> it kind of depends on the CPU I think how fast a certain subroutine should be :p
20:59:16 <TrueBrain> we might need to make some real timing there ...
21:09:31 <glx> ok I found the broken one
21:10:13 <TrueBrain> so go back to the store :)
21:20:51 <glx> windows still doesn't boot
21:24:55 <glx> I had 4*1GB :), but one is dead and I can't use 3*1GB
21:49:04 *** ChanServ sets mode: +o glx_
21:49:46 *** glx is now known as Guest83
continue to next day ⏵