-------------------------------------------------------------------------------------------------------------------------------------------- 16:19 < ais523+> FIQ: so in a case like this, where you're trying to diagnose runtime behaviour 16:19 < ais523+> the easiest way to use gdb is in "attach" mode 16:19 < ais523+> to start it up like that, you open a new terminal 16:20 < ais523+> then type "gdb --pid " and the process's PID (note: this may need root perms in some configurations) 16:20 < ais523+> and then at the prompt, type "c" (normally there's no time limit for doing so, but when using NH4 in server/client mode, you often have to do it within 3 seconds because otherwise the process you're not debugging will time out) 16:21 < ais523+> "c" means continue, it tells gdb to let the process run normally 16:21 < ais523+> at any given time, the process is in one of two modes: trace-stop, when you have full control over how it runs 16:21 < ais523+> or running freely 16:21 < ais523+> gdb places processes into trace-stop when you attach to them, but you want them to be running freely most of the time 16:22 < ais523+> and only "breaking into" trace-stop to look at something in details 16:25 < ais523+> FIQ: anyway, if you want to try using gdb, get gdb attached to the client and server 16:25 < ais523+> and then I can explain the next step 16:25 < ais523+> (and both of them running freely) 16:25 < ais523+> you might need to mess about with pgrep or top a bit to find the correct process numbers 16:25 < FIQ > ok, just a moment 16:26 < FIQ > going to replicate the issue I am having atm so I can do something productive 16:29 < FIQ > I want to do --pid on the client I guess? 16:29 < FIQ > wait, they share process, nvm 16:30 < FIQ > there 16:30 < FIQ > I pressed c and can still play 16:30 < ais523+> FIQ: depends on whether you're using a server/client setup or just client 16:30 < FIQ > currently just client 16:30 < ais523+> what are you trying to debug right now, out of interest? 16:31 < FIQ > a desync in bones loading 16:31 < ais523+> anyway, in order to get back into trace-stop, you can press ctrl-c in the gdb window 16:31 < ais523+> (and likewise, c to get back to free running, so you can go back and forth) 16:31 < FIQ > hmm but wouldn't that time out stuff as you said? 16:31 < ais523+> FIQ: not in a client-only setup 16:31 < ais523+> debugging there's way easier 16:32 < ais523+> the problem with server/client is that if you stop one, the other one times out waiting for it 16:32 < FIQ > ahh 16:32 < FIQ > maybe it should be possible to configure that 16:32 < FIQ > hmm 16:32 < ais523+> that's actually a really good idea 16:32 < jonadab+> At compile time, it should be. 16:32 < jonadab+> For debugging purposes. 16:32 < ais523+> compile-time would do 16:32 < FIQ > wait, this is not replicating the issue >_> 16:32 < FIQ > it is just segfaulting instead, for some reason 16:32 < ais523+> or the other trick is to make it a volatile global 16:32 < FIQ > sorry, I will look into it further 16:32 < ais523+> FIQ: well, if you get a segfault 16:33 < ais523+> while the process is being debugged 16:33 < ais523+> gdb will enter trace-stop just before the program ends 16:33 < ais523+> to let you look at what caused it 16:33 < FIQ > ahh 16:33 < jonadab+> And you can type backtrace 16:33 < jonadab+> That's the _one_ thing I know how to do with gdb. 16:33 < ais523+> by default, it'll spontaneously stop any program that segfaults even if you don't tell it to 16:33 < ais523+> the most useful command here is "backtrace", which everyone but jonadab abbreviates "bt" 16:33 < FIQ > Program received signal SIGSEGV, Segmentation fault. 16:33 < FIQ > 0x00007f7ebe80c63b in prop_wary (mon=mon@entry=0x2326f60, target=target@entry=0x0, prop=prop@entry=REFLECTING) at /home/fiq/fiqhack/libnethack/src/prop.c:350 16:33 < FIQ > 350 (target != &youmonst && mon->mpeaceful == target->mpeaceful) || 16:34 < FIQ > hm, interesting 16:34 < FIQ > ais523: ah, I see 16:34 < FIQ > hmm 16:34 < ais523+> that'll tell you what the program was doing at the time: the top of the list is most specific, the bottom is most general 16:34 < ais523+> so at the bottom of the list you'll see that main() was running, and at the top of the list, you'll have prop_wary 16:34 < ais523+> then you look at the list and try to work out which function the problem was in 16:34 < ais523+> atm, we can se that target@entry was NULL 16:34 < ais523+> and if prop_wary isn't meant to have a NULL argument, then the fault must have been with the function that called it, or its caller, and so on 16:34 < FIQ > what does the @entry part mean? 16:35 < ais523+> value when the function started 16:35 < FIQ > ais523: prop_wary can have a NULL argument, but not for target 16:35 < ais523+> functions can change the values of their arguments as they run 16:35 < ais523+> they normally don't 16:35 < ais523+> FIQ: right, so the problem was with the caller 16:35 < ais523+> now, you can focus on any of the functions that are running 16:35 < ais523+> known as "frame"s 16:35 < ais523+> at the moment we're in frame 0, the innermost function 6:36 < ais523+> if you try giving "frame 1" then we can have a look at what the caller was doing 16:36 < FIQ > ah 16:36 < ais523+> FIQ: "bt" shows you the entire list, it's like a minimap for gdb 16:36 < FIQ > what does bt do, then? 16:36 < FIQ > ah 16:36 < ais523+> technically you never need to know it but it helps to prevent you getting lost 16:36 < ais523+> it's the difference between a roguelike (bt) and a text adventure (no bt) 16:37 < FIQ > actually 16:37 < FIQ > I think I see the issue, already 16:37 < FIQ > I did frame 1 16:38 < FIQ > to see where it was called 16:38 < FIQ > it said this 16:38 < FIQ > #1 0x00007f7ebe8b444d in mon_choose_dirtarget (mon=mon@entry=0x2326f60, obj=obj@entry=0x22c3b30, cc=0x7ffdf93e4480, cc@entry=0xc) 16:38 < FIQ > at /home/fiq/fiqhack/libnethack/src/muse.c:638 16:38 < FIQ > 638 prop_wary(mon, mtmp, REFLECTING)) { 16:38 < FIQ > so I went ahead and looked at the code there 16:38 < ais523+> you can actually type "list" to get context 16:38 < FIQ > and I see a rather obvious problem 16:38 < ais523+> saves you having to open the editor 16:38 < FIQ > ahh 16:38 < FIQ > neat 16:38 < ais523+> or just "l" I think 16:39 < ais523+> that basically just gets gdb to open up the file itself and copy the lines 16:39 < FIQ > list does not give the offending line I was referring to, though 16:39 < FIQ > yeah, fair 16:39 < FIQ > can you make it give a larger context? 16:39 < FIQ > e.g. 10 lines at both directions 16:39 < ais523+> ah right, normally an editor's better if the situation isn't very simple 16:39 < ais523+> I think you do something like "l 628,648" 16:39 < ais523+> might be a hyphen rather than a comma 16:39 < FIQ > Well, the issue was literally 2 lines above where it outputted 16:39 < FIQ > Ah 16:39 < FIQ > That works 16:40 < FIQ > And gives away the issue 16:40 < ais523+> anyway, your program isn't very useful after it's segfaulted 16:40 < FIQ > indeed 16:40 < ais523+> so once you've found the problem, you can't do much other than "c" (which will let it crash), or "k"="kill" (to forcibly exit it from the debugger) 16:41 < ais523+> the debugger itself is exited using "q" or control-D -------------------------------------------------------------------------------------------------------------------------------------------- 16:59 < FIQ > ok I am in gdb 16:59 < FIQ > let's see 17:00 < FIQ > ok so I tried to go into "trace stop" or whatever it was called, and did a bt 17:00 < FIQ > but the output is not very helpful 17:00 < ais523+> right 17:00 < FIQ > #18 0x0000000000414908 in loadgame () at /home/fiq/fiqhack/nethack/src/rungame.c:728 17:00 < FIQ > #19 0x00000000004046d2 in mainmenu () at /home/fiq/fiqhack/nethack/src/main.c:297 17:00 < FIQ > #20 main (argc=2, argv=) at /home/fiq/fiqhack/nethack/src/main.c:361 17:00 < FIQ > since it is being in the desync dialog 17:01 < ais523+> OK, so the next thing you can do 17:01 < ais523+> is to go to frame 18 17:01 < ais523+> look at the lines about there 17:01 < FIQ > I assume I should recover and cause it again, but how do I get the info I want? 17:01 < FIQ > ah, ok 17:01 < ais523+> and start asking for the values of variables 17:01 < ais523+> you can evaluate any expression using "p " and the expression 17:01 < ais523+> so the simplest use is along the lines of "p mtmp" 17:02 < FIQ > frame 18 is "728 ret = playgame(fd, FM_PLAY);", I assume this is where you meant? 17:02 < ais523+> FIQ: I was going along the lines of the "#18 0x0000000000414908 in loadgame () at /home/fiq/fiqhack/nethack/src/rungame.c:728" 17:02 < ais523+> looks like the numbers are different from in your quote above though 17:03 < FIQ > Well, it looks the same? 17:03 < FIQ > frame 18 -> rungame:728 17:03 < FIQ > and frame 18 is line 728 in rungame 17:03 < FIQ > (as pasted below) 17:03 < ais523+> ah right 17:03 < ais523+> in that case we should be looking higher up (i.e. lower frame numbers) 17:03 < ais523+> if you like you can paste the backtrace and I can see if I can guess which frame to look at 17:04 < ais523+> (sometimes you can't guess, and have to check all of them) 17:04 < FIQ > ok one sec 17:04 < ais523+> the worst situation is if the information you need isn't in any of them, in which case you need to do dynamic debugging (i.e. getting the debugger to look for things while the program runs), which is rather more difficult 17:04 < FIQ > http://sprunge.us/LCOP 17:04 < FIQ > is the entire thing (gdb) backtrace #0 0x00007f87c980ce03 in __select_nocancel () from /usr/lib/libc.so.6 #1 0x00007f87cbfd1141 in platform_specific_getkeystring (ignore_signals=0, timeout_ms=-1) at /home/fiq/fiqhack/libuncursed/src/plugins/tty.c:490 #2 getkeyorcodepoint_inner (timeout_ms=-1, ignore_signals=0) at /home/fiq/fiqhack/libuncursed/src/plugins/tty.c:1009 #3 0x00007f87cbfcd6f9 in uncursed_hook_getkeyorcodepoint (ms=-1) at /home/fiq/fiqhack/libuncursed/src/libuncursed.c:412 #4 timeout_get_wch (timeout=-1, rv=0x7ffe5ce4a58c) at /home/fiq/fiqhack/libuncursed/src/libuncursed.c:2701 #5 0x00007f87cbfcfdba in wgetch (win=win@entry=0x266e740) at /home/fiq/fiqhack/libuncursed/src/libuncursed.c:2818 #6 0x000000000040768d in nh_wgetch (win=0x266e740, context=context@entry=krc_menu) at /home/fiq/fiqhack/nethack/src/windows.c:1343 #7 0x0000000000408e1e in curses_display_menu_core (ml=ml@entry=0x7ffe5ce4c0d0, title=title@entry=0x7f87cbd2a408 "The save file is corrupted...", how=how@entry=1, callbackarg=callbackarg@entry=0x7ffe5ce4c0c0, callback=callback@entry=0x7f87cbc6feb0 , x1=, y1=0, x2=158, y2=42, bottom=0 '\000', changefn=0x0, dismissable=1 '\001') at /home/fiq/fiqhack/nethack/src/menu.c:457 #8 0x000000000040949a in curses_display_menu (ml=0x7ffe5ce4c0d0, title=0x7f87cbd2a408 "The save file is corrupted...", how=1, placement_hint=3, callbackarg=0x7ffe5ce4c0c0, callback=0x7f87cbc6feb0 ) at /home/fiq/fiqhack/nethack/src/menu.c:659 #9 0x00007f87cbc9cee7 in display_menu (menu=menu@entry=0x7ffe5ce4c150, title=title@entry=0x7f87cbd2a408 "The save file is corrupted...", how=how@entry=1, placement_hint=placement_hint@entry=3, results=results@entry=0x7ffe5ce4c148) at /home/fiq/fiqhack/libnethack/src/windows.c:320 #10 0x00007f87cbbe0f55 in log_recover_core (offset=10663, canreturn=canreturn@entry=0 '\000', message=message@entry=0x27097b0 "desync at 33099 (20:2a + 50 bytes), was 24 is 4f", file=file@entry=0x7f87cbd2a528 "/home/fiq/fiqhack/libnethack/src/log.c", line=line@entry=1981) at /home/fiq/fiqhack/libnethack/src/log.c:275 #11 0x00007f87cbbe0934 in log_recover_noreturn (offset=, message=message@entry=0x27097b0 "desync at 33099 (20:2a + 50 bytes), was 24 is 4f", file=file@entry=0x7f87cbd2a528 "/home/fiq/fiqhack/libnethack/src/log.c", line=line@entry=1981) at /home/fiq/fiqhack/libnethack/src/log.c:351 #12 0x00007f87cbbe3098 in load_gamestate_from_binary_save (maybe_old_version=maybe_old_version@entry=0 '\000') at /home/fiq/fiqhack/libnethack/src/log.c:1980 #13 0x00007f87cbbe34a3 in log_neutral_turnstate () at /home/fiq/fiqhack/libnethack/src/log.c:1216 #14 0x00007f87cbbe5c02 in neutral_turnstate_tasks () at /home/fiq/fiqhack/libnethack/src/decl.c:301 #15 0x00007f87cbbd8106 in nh_play_game (fd=fd@entry=6, followmode=, followmode@entry=FM_PLAY) at /home/fiq/fiqhack/libnethack/src/allmain.c:680 #16 0x00007f87ca9a6ffd in nhnet_play_game (gid=gid@entry=6, followmode=FM_PLAY) at /home/fiq/fiqhack/libnethack_client/src/clientapi.c:158 #17 0x0000000000413efd in playgame (fd_or_gameno=fd_or_gameno@entry=6, followmode=followmode@entry=FM_PLAY) at /home/fiq/fiqhack/nethack/src/rungame.c:754 #18 0x0000000000414908 in loadgame () at /home/fiq/fiqhack/nethack/src/rungame.c:728 #19 0x00000000004046d2 in mainmenu () at /home/fiq/fiqhack/nethack/src/main.c:297 #20 main (argc=2, argv=) at /home/fiq/fiqhack/nethack/src/main.c:361 17:05 < ais523+> FIQ: aha, frame 12 is the one we want 17:05 < ais523+> because frame 11 is an error-handling function, thus its caller must be the function that found the error 17:05 < FIQ > 1980 log_recover_noreturn(get_log_offset(), mequal_message, 17:05 < FIQ > is 12 17:05 < ais523+> that said, it looks like we're past the point at which the error happened 17:06 < FIQ > Mhm 17:06 < ais523+> because it's compared the old and new save files and discovered they aren't equal 17:06 < FIQ > Making debugging not possible in this context, in other word? So I need to do it while running, or? 17:06 < FIQ > *other words 17:06 < ais523+> actually, I know what causes that particular desync 17:06 < ais523+> (I knew before but forgot to realise/mention it 17:06 < ais523+> ) 17:07 < ais523+> I think what's happened is that a monster's believing that the player's location is on top of the monster itself 17:07 < ais523+> which could well be related to your displacement changes 17:07 < FIQ > Hm, that would make sense, but I think I check for that actually 17:07 < ais523+> (I think this may be the reason why each monster sees a player's displaced image in a different location, because it prevents that confusing case happening) 17:08 < FIQ > Also, there is no displacement going on at the moment in the bones 17:08 < FIQ > unless I broke something, thta is 17:08 < ais523+> if you have mux/muy = ux/uy, it looks like a save from 4.3-beta1 (which contained a bug in mux/muy encoding) 17:08 < FIQ > *that 17:08 < ais523+> and gets overcorrected 17:08 < ais523+> you might just want to remove that save compat shim from fiqhack on the basis that the case can't occur (grep for SAVEBREAK) 17:09 < FIQ > Also, I have not currently coded the monster AI to take into account my displacement changes, yet 17:09 < FIQ > OK I will look into it 17:10 < FIQ > /* SAVEBREAK (4.3-beta2alpha -> 4.3-beta2): this is for reading old saves 17:10 < FIQ > you mean this? 17:10 < FIQ > yeah that should not be relevant 17:10 < FIQ > for my variant 17:10 < FIQ > I will try removing that case 17:11 < FIQ > However, I am not sure if this is the bug unless I broke something horribly, mostly since displacement is currently not happening 17:11 < FIQ > Oh well, I'll try anyway 17:11 < ais523+> ah right, beta2alpha, not beta1 17:12 < FIQ > OK, I went ahead and removed that code 17:12 < FIQ > and recompiled the thing 17:12 < FIQ > recovered, quit and restarted the game 17:12 < FIQ > (and attached a new gdb) 17:13 < FIQ > I got the same error, though 17:13 < FIQ > And I ran bt 17:13 < ais523+> right 17:13 < FIQ > different offsets aside, they are the same 17:14 < FIQ > so it is not merely a new bug 17:14 < ais523+> so the next step is to have a look at the two sets of gamestate and compare them 17:14 < FIQ > hmm 17:15 < ais523+> we can't ctrl-c interrupt the game at the moment just before it's saved ourself 17:15 < ais523+> so we'll have to ask gdb to do it for us 17:15 < ais523+> get into the position to reproduce the bug, but stop one keystroke beforehand 17:15 < ais523+> then enter trace-stop 17:16 < FIQ > ais523: k, I am at the "Unlink bones? [yn] (n)" dialog 17:16 < FIQ > which is one keystroke before it happens 17:16 < ais523+> right 17:17 < ais523+> so now we tell gdb where we want to stop the program, using the "b" command, that lets us give a file and line number 17:17 < ais523+> in this case we want to stop just before the game is saved 17:17 < ais523+> so we can do "b savegame" 17:17 < ais523+> (because that's the function that saves the game) 17:17 < FIQ > I assume I enter trace-stop, run ^, continue the game, and press n? 17:17 < FIQ > Just checking 17:17 < ais523+> that's it 17:18 < ais523+> this way you can stop the program at very precise times to look at it 17:18 < FIQ > there we go 17:19 < ais523+> so now we need to consider what's interesting to look at 17:19 < FIQ > hmmm 17:19 < FIQ > The desync dialog 17:19 < ais523+> in this case, the desync dialog is mentioning monster 2a 17:19 < FIQ > implies that it is a monst struct going wrong, and it is muxy 17:19 < FIQ > right? 17:19 < ais523+> yep 17:19 < ais523+> we need to find it 17:19 < ais523+> so we can start by doing "p level->fmon" to see if the fmon pointer (start of the monster chain) is valid 17:20 < FIQ > so 2a here is monster ID 2a 17:20 < ais523+> 0x2a 17:20 < FIQ > fmon? you mean monlist or? 17:20 < FIQ > I tried fmon 17:20 < ais523+> one general rule about debugging is that you need to check that pointers aren't NULL before you try to dereference them 17:20 < ais523+> I meant monlist, sorry 17:20 < FIQ > yeah 17:20 < FIQ > makes sense 17:20 < ais523+> if the pointer's valid 17:20 < FIQ > (why fmon, out of curiousity?) 17:20 < ais523+> we can then do "p *(level->monlist)" 17:20 < FIQ > monlist is valid 17:20 < ais523+> I thought that's what the monster chain was called 17:21 < FIQ > hm, ok 17:21 < ais523+> maybe it's called fmon in some other struct, or in vanilla, or something 17:21 < FIQ > Ah 17:21 < FIQ > Makes sense 17:21 < FIQ > m_id 42 17:21 < FIQ > hmm 17:21 < FIQ > what is that in hex 17:21 < FIQ > 2a 17:21 < FIQ > so that is the offending monster 17:22 < ais523+> FIQ: you can do "p/x 42" to convert a number from decimal to hex 17:22 < FIQ > ah, neat 17:22 < ais523+> (well, 42 is the number you're converting in this case) 17:22 < ais523+> so now you can look at the monster to see if anything's weird 17:22 < FIQ > hmm, in this case mx is 36, my is 7 17:22 < FIQ > 36 is 24 in hex, giving the above desync 17:22 < FIQ > hmm 17:22 < ais523+> are mx/my equal to mux/muy? 17:23 < FIQ > it is 17:23 < ais523+> right 17:23 < FIQ > hmm, is that really right? 17:23 < ais523+> maybe you removed the save compat thing from the wrong place? 17:24 < FIQ > one moment 17:24 < ais523+> it might have been in two places (save and restore) 17:24 < FIQ > ohhh 17:24 < FIQ > I removed in restore_mon 17:24 < FIQ > let's see save mon 17:24 < FIQ > hm 17:25 < FIQ > there is no other SAVEBREAK 17:25 < ais523+> not sure about that particular one though 17:25 < FIQ > and save_mon does not have the above case 17:25 < ais523+> because it was meant for fixing bugginess in old save files 17:25 < ais523+> there might still be something that assumes that mux/muy != mx/my, though 17:25 < ais523+> basically because it doesn't make logical sense 17:25 < ais523+> a monster shouldn't assume you're on its square, because it knows that it's on its square 17:25 < FIQ > engulfers -- but otherwise, yeah 17:25 < ais523+> (there are some awkward special cases to do with engulfing) 17:26 < FIQ > I don't quite understand how this showed up when I started messing with bones code, unless bones code was broken in NH4 already 17:26 < FIQ > Anyway, as seen, muxy is equal to mxy 17:26 < FIQ > Which is.. wrong 17:27 < FIQ > now I wonder *why* this is 17:27 < FIQ > Hm, I wonder 17:27 < FIQ > Bones saves a monster 17:27 < ais523+> check to see if they're equal at the end of the previous neutral turnstate 17:27 < FIQ > I am pretty sure 2a did not exist at last neutral turnstate 17:27 < FIQ > since this is loading bones 17:27 < ais523+> (and/or if monster 42 is even there) 17:27 < ais523+> right 17:28 < ais523+> what caused the bones file to be left? 17:28 < ais523+> i.e. how did you die in the game that the bones is being loaded from? 17:28 < ais523+> and is it an old bones or a recent one? 17:28 < FIQ > I deliberately left it in wizard mode after killing myself by pressing s multiple times while enemies whacked me to death 17:28 < FIQ > It was multibones 17:28 < FIQ > I can look into my last game 17:29 < FIQ > to see the exact cirumstances 17:29 < ais523+> might be worth checking if the monster in question had mxy=muxy 17:29 < ais523+> if we can identify which one it was, the ID number will be different 17:30 < FIQ > "Wizard swings his quarterstaff. Wizard hits! You die... now let's see here 17:30 < FIQ > monster at 36,7 17:32 < ais523+> check level->monsters[36][7], then (using p) 17:32 < ais523+> and dereference it if it's not a NULL pointer 17:32 < FIQ > right 17:32 < FIQ > struct monst 0x0 17:33 < FIQ > one moment, I will just check ux/uy 17:33 < FIQ > hm 17:33 < FIQ > how do I do that? 17:33 < FIQ > (gdb) p u 17:33 < FIQ > No symbol "u" in current context. 17:34 < FIQ > anyway the reason I want to check ux/uy 17:34 < FIQ > is in case the offending monster is the late player 17:34 < FIQ > in which his coordinates would be 36 7 17:34 < ais523+> FIQ: "u" is a macro 17:34 < ais523+> it translates to "gamestate.us[0]" 17:34 < FIQ > ah 17:34 < ais523+> it's part of a project to move globals into more sensible places 17:34 < FIQ > $4 = {ux = 36 '$', uy = 10 17:35 < FIQ > hm... that is not what I wanted to see 17:35 < ais523+> (which is what was causing khoR's build error earlier) 17:35 < FIQ > but also this seems to imply that there is a monster 3 rows above 17:35 < FIQ > the player 17:35 < FIQ > but I don't see any 17:36 < FIQ > (it's not outlandish because it is not outside a wall or something silly like that) 17:36 < ais523+> maybe the screen hasn't updated yet 17:36 < ais523+> at what moment did you tracestop the game? 17:36 < FIQ > 1 turn before the kill 17:37 < FIQ > I will try doing it at the actual kill 17:37 < FIQ > ok 17:37 < FIQ > so I did that 17:37 < FIQ > and checked 36, 7 17:38 < FIQ > it is still a null pointer 17:38 < FIQ > hm... 17:38 < FIQ > I will check to see exactly what monster that caused the desync 17:38 < FIQ > e.g. beyond ID 17:38 < ais523+> you could check for monster species, that might help narrow it down a bit 17:39 < ais523+> you can call object/monster naming functions via the debugger (during the BUFSZ purge, I designed the new versions of the functions so that that would work) 17:40 < FIQ > (gdb) p Monnam(*(level->monlist)) 17:40 < FIQ > $6 = 0xd731a0 "Wizard" 17:40 < FIQ > that is a player ghost 17:40 < FIQ > hmm 17:40 < FIQ > s/ghost/monster/ 17:40 < FIQ > wait what? 17:40 < ais523+> is that the monster that was causing the desync when the bones are loaded? 17:41 < ais523+> might be best to get both games loaded and debugger-ed up at the same time 17:41 < FIQ > Yes, but I am getting conflicting things here 17:41 < ais523+> the leaving one and the loading one 17:41 < FIQ > Because I am doing p Monnam(*(level->monlist)) 17:41 < FIQ > giving "Wizard" 17:41 < ais523+> FIQ: Monnam takes a pointer 17:41 < ais523+> you want p Monnam(level->monlist) 17:41 < FIQ > Oh 17:41 < FIQ > right 17:41 < FIQ > Ok, that makes more sense 17:41 < ais523+> unlike a compiler, a debugger won't notice that you're asking it to do nonsensical things 17:42 < FIQ > It's a kitten 17:42 < FIQ > Yeah, indeed 17:42 < FIQ > I was just being silly 17:42 < FIQ > Anyway, kitten means a pet 17:42 < FIQ > So it doesn't seem to have been caused by the player monster itself (which I assumed), which is interesting 17:42 < FIQ > But then I wonder exactly what happened and why 17:43 < FIQ > Hmm 17:43 < FIQ > It seems to be tame 17:44 < FIQ > Which is rather strange, unless it is the kitten that originated on dlvl1 together with me 17:44 < FIQ > OK, I will rewind a bit 17:44 < FIQ > and see if this is the case 17:44 < FIQ > (by checking my pet's m_id) 17:45 < FIQ > ais523: how do I continue a breakpoint? 17:45 < FIQ > ok 17:45 < FIQ > just c worked 17:45 < ais523+> right, c will always cause the program to start running freely 17:45 < ais523+> until the next breakpoint or ctrl-c 17:46 < FIQ > OK, yes, it is that cat 17:46 < FIQ > I rewinded to dlvl1 17:46 < FIQ > *rewound 17:47 < FIQ > Did a level->monlist check 17:47 < FIQ > And 2a still exists 17:47 < FIQ > being my pet 17:47 < FIQ > Hm 17:47 < FIQ > So maybe the desync isn't actually caused by bones loading? Allthough I don't know what it would be caused by otherwise 17:48 < ais523+> does the cat have muxy=mxy at this moment? 17:48 < FIQ > it has mux=79, muy=21 17:48 < FIQ > e.g. colno/rowno 17:48 < FIQ > (mx/my being 17,10) 17:50 < FIQ > hmm 17:51 < FIQ > this makes me wonder 17:51 < FIQ > if the mere act of wizporting (or perhaps just levelporting) with pets occasionally create issues 17:51 < FIQ > and/or if loading the bones when kitten isn't following works fine 17:52 < ais523+> it's worth a test 17:52 < FIQ > and/or if this issue exists in NH4, because at this point I'm not sure if it is my own code, or at the very least not bones code 17:52 < FIQ > ok I'll create a save backup and mess around a bit 17:52 < ais523+> hmm, you know the position that you arrive on at the bones level? does that happen to be equal to or adjacenet to your position at the level above? 17:52 < ais523+> I'm wondering if a set of coordinates is being copied over from one level to another 17:52 < ais523+> that'd explain why it hadn't been seen before, if true 17:52 < FIQ > it is rather far from it 17:53 < ais523+> ah right 17:53 < FIQ > wait, or is it? 17:53 < FIQ > sec 17:53 < FIQ > Yeah 17:53 < FIQ > it's far from it 17:54 < FIQ > I'm at 16,10ish and the desync happened at kitten at 36,7 at oracle (so in the big oracle room) 17:54 < FIQ > (kitten is at 17,10 apparently, according to myself earlier) 17:56 < FIQ > levelporting w/o kitten works 17:57 < FIQ > ha 17:57 < FIQ > got ya 17:57 < FIQ > so I tried to levelport 17:57 < FIQ > all over the dungeon 17:57 < FIQ > w/o bones 17:58 < FIQ > once I got to dlvl19 17:58 < FIQ > I got the same desync 17:58 < FIQ > this time w/o bones 17:58 < FIQ > Error: desync at 325689 (20:2a + 50 bytes), was 16 is 4f 17:58 < jonadab+> Still the kitten. 17:58 < FIQ > hmm 17:58 < FIQ > yep 17:58 < FIQ > I will try to replicate in NH4 and fourk 17:58 < FIQ > and see if this is a more general issue or still in my own code 17:59 < ais523+> clearly it's not to do with the starting pet generally, or we'd have had problems before now 17:59 < ais523+> must be something specific about it 18:01 < FIQ > oh wow 18:01 < FIQ > it took much longer this time 18:01 < FIQ > but I got the same desync in fourk 18:01 < FIQ > wait, that might not be true 18:01 < FIQ > because fourk has a level desync bug already 18:01 < FIQ > OK, let me try in NH4 18:01 < FIQ > Error: desync at 50555 (20:69 + 52 bytes), was 3e is 4f 18:01 < FIQ > error is quite similar though 18:02 < FIQ > (Bytecount is different, but that's because fourk has the 4 unused bytes still present, but at the same time lacks dx/dy, so 52 is mux) 18:05 < FIQ > aaand replicated in NH4 18:05 < FIQ > Error: desync at 491688 (20:2c + 52 bytes), was 03 is 4f 18:05 < FIQ > So yeah, the error appears to have nothing to do with my bones code 18:05 < FIQ > (There might of course be bugs in my bones code, but it isn't causing this particular issue) 18:06 < FIQ > Hmm 18:06 < FIQ > ais523: do you want a copy of the save with a realibly 18:07 < ais523+> I'm not sure I have the concentration to look into it right now 18:07 < ais523+> especially as it's a fiqhack save 18:07 < FIQ > Fair enough 18:07 < FIQ > It is a NH4 save 18:07 < FIQ > now 18:07 < ais523+> ah, hmm 18:07 < ais523+> in that case it's more useful 18:07 < FIQ > As said, I was trying to repro in NH4+friends 18:07 < ais523+> put it online somewhere and I'll download it and maybe look at it later 18:07 < FIQ > To see if it was my own code 18:07 < FIQ > or in general 18:07 < FIQ > OK 18:07 < FIQ > Um 18:07 < FIQ > How should I tell how to repro the bug? 18:08 < FIQ > eh w/e, one moment 18:08 < FIQ > I'll just throw up a html on my desktop with download link + how to repro 18:08 < FIQ > dirty, but works 18:09 < FIQ > jonadab: so, khor was having general issues with crashes 18:09 < FIQ > khor is playing pacifist 18:09 < FIQ > this might be related 18:09 < FIQ > to the same bug 18:09 < FIQ > just an idea 18:11 < FIQ > oh ffs 18:11 < FIQ > a new ip *today*, really? 18:11 < FIQ > anyway 18:12 < FIQ > ais523: http://195.198.149.106/save.html for future reference 18:12 < FIQ > that should work for a few months 18:12 < FIQ > (I have a saner domain that worked as late as yesterday, seems like my IP changed today...) 18:12 < ais523+> FIQ: ".html"? 18:12 < FIQ > ais523: Intentional 18:12 < FIQ > Follow it 18:13 < FIQ > It is to give you a short explanation on how to repro 18:13 < ais523+> oh bleh, I was trying to use wget 18:13 < FIQ > Sorry 18:13 < FIQ > The actual save is here: http://195.198.149.106/1444687464_.nhgame 18:13 < coppro+> ais523 can see URLs now? 18:13 < FIQ > The above merely shows this: Reproduce: Use wiztele (^V) to Dlvl27 Download: here 18:13 < ais523+> FIQ: 403 18:13 < FIQ > ... 18:13 < FIQ > >_< 18:13 < ais523+> coppro: I've been able to for years, I changed them to be unstyled rather than hidden a while back 18:14 < FIQ > why are you doing this to me apache 18:14 < FIQ > ok, one moment 18:14 < ais523+> FIQ: the perms probably aren't set to "readable by other" 18:14 < ais523+> NH4 uses o-r perms on save files by default 18:14 < FIQ > oh 18:14 < FIQ > ok 18:14 < ais523+> which would be more secure if not for the fact that the player owns them and thus can read them via the u+r 18:15 < FIQ > OK, now it worked 18:15 < FIQ > http://195.198.149.106/1444687464_.nhgame 18:15 < ais523+> got it, thanks 18:15 < FIQ > If it still doesn't work, I give up and will try finding a file host.. 18:15 < FIQ > ok, good 18:16 < ais523+> coppro: mostly because the URL itself often has useful information even if I don't follow it 18:18 < FIQ > ais523: sorry for giving you some hassle 18:18 < FIQ > also, thanks for teaching me some gdb-fu :)