#exult@irc.freenode.net logs for 4 Nov 2012 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[00:37:59] <Marzo> wjp, Colourless, Kirben: did you by any chance saw the message I forwarded to the Exult list some days ago about an interview with Ultima Codex? If not, would you be interested in participating in such an interview?
[03:21:21] <-- shazza has left IRC (Ping timeout: 256 seconds)
[03:21:44] --> shazza has joined #exult
[03:55:32] <-- Marzo has left IRC (Ping timeout: 248 seconds)
[04:09:55] --> Kirben_ has joined #exult
[04:09:55] --- ChanServ gives channel operator status to Kirben_
[04:10:54] <-- Kirben has left IRC (Ping timeout: 264 seconds)
[05:26:04] <-- jvlee has left IRC (Remote host closed the connection)
[11:09:47] <Dominus> hmm, got to manage to meet marzo :)
[11:11:17] <Dominus> in Rev 7110 he fixed a cache-out memory leak in objs.cc. Unfortunately this seems to cause some problems on cache-in. http://sourceforge.net/tracker/?func=detail&atid=102335&aid=3577501&group_id=2335
[11:11:47] <Dominus> When I revert this I cannot reproduce the problem anymore. but I'm still going to try and reproduce it some more...
[11:16:01] <-- Matt_O has left IRC (Read error: Connection reset by peer)
[11:16:13] --> Matt_O has joined #exult
[11:30:30] <wjp> hm
[11:32:19] <Dominus> I didn't think it would make *any* difference whether to exclude this"chunk->get_map()->is_caching_out" right away or returning when this is true
[11:33:11] <wjp> the final statement in that function is being called, now that the return is gone
[11:36:40] <Dominus> hmm, still don't get it. with "if (chunk && !nodel && !chunk->get_map()->is_caching_out())" the final statement wouldn't be called either if "chunk->get_map()->is_caching_out" was true, I think. Not sure though...
[11:37:05] <wjp> Game_object::remove_this(nodel); is outside of this if
[11:37:14] <wjp> so it's always called in current svn
[11:38:23] <wjp> while before r7110 it would have been bypassed by the return
[12:03:28] <Dominus> right, I understand.
[12:04:17] <Dominus> so an else if "chunk->get_map()->is_caching_out" return might help the issue of iolo but wouldn't fix part of the memory leak I guess.
[12:04:33] <Dominus> No time to check, lunch time and baby time.... etc :)
[12:18:49] <-- Kirben_ has left IRC ()
[14:09:07] --> Marzo has joined #exult
[16:21:36] <Dominus> Marzo: I'm in the midst of preparing dinner for the little one but can you take a look at the cache-out/in and memory leak problem? See the logs of today for a brief discussion between wjp and me
[16:21:48] <Marzo> I saw
[16:22:01] <Marzo> Can't help much this week, I am swamped
[16:22:16] <Dominus> okeydokey
[16:22:32] <Dominus> thanks anyway :)
[16:25:31] <wjp> Marzo: do you think it would be an option to revert that change to Terrain_game_object::remove_this and look at the leak again later?
[16:26:34] <Marzo> The leak made the disappearing objects bug worse; if it is still lurking there, we could see a resurgence
[16:27:57] <wjp> Hm, do you mean it wasn't a memory leak?
[16:28:53] <Marzo> No; I am just saying that there was one guy claiming that this memory leak was the cause of the disappearing objects bug as it almost stopped after this leak got fixed
[16:29:18] <wjp> ("memory leak" kind of implies a bug without any harm other than slowly running out of memory)
[16:30:28] <Marzo> I think that it made the disappearing objects bug worse because the memory exhaustion likely favored the kind of scenarios that I think caused the disappearing objects bug
[16:30:44] <wjp> what exactly would get exhausted?
[16:30:49] <Marzo> Memory
[16:31:10] <wjp> huh? Do we behave differently when running low on memory?
[16:31:17] <wjp> (maybe I missed something)
[16:32:26] <Marzo> No; the disappearing objects bug seems to happen more often on long play sessions (but we never could confirm that)
[16:33:13] <Marzo> There were a couple of possible causes for that bug that involved some pretty long shots, including double deletes and so on
[16:33:35] <Marzo> It is possible that the long play sessions coupled with the memory leak favored these cases
[16:33:55] <Marzo> I am just guessing here, as we never could definitely identify what caused the disappearing objects bug
[16:34:35] <Marzo> But, as I said, there was that guy that claimed that this leak caused the disappearing objects bug because it seemed to go away after the leak got fixed
[16:37:07] <wjp> it doesn't make sense to call this a memory leak, though. Some caching issue possibly, but if so the leak symptom of this wouldn't be responsible
[16:37:46] <wjp> anyway, guess we have to examine caching in/out closely :-(
[16:38:36] <Marzo> Yeah... and the worse part is that it is a mess...
[16:39:12] <wjp> I wonder if currently the walls to Iolo's cell only show up after he's had a chance to wander out :-)
[16:39:36] <Marzo> It is possible
[16:39:50] * wjp remembers a fun bug in pentagram where people would fall through the floor by walking out of the cached-in area :-)
[16:39:56] <Marzo> Or maybe he can still somehow move after his chunk is cached out
[16:40:24] <wjp> also quite possible
[16:44:57] <wjp> it would be interesting to use the cheat screen to spy on Iolo while reproducing this to see when exactly he moves
[16:51:25] <wjp> hm, sometime soon after a superchunk gets killed
[16:53:08] <wjp> yes
[16:53:28] <wjp> Iolo continues moving after "Killing superchunk: 112"
[16:54:50] <wjp> so looks like you're right :-)
[17:04:31] <Marzo> wjp: saw my message from yesterday?
[17:08:11] <wjp> hm, not sure how much I will be able to remember :-)
[17:14:02] <sh4rm4> May 06 19:53:19 <sh4rm4> and as i said, the real fix is the memleak in the int->bool commit
[17:14:03] <sh4rm4> May 06 19:56:42 <sh4rm4> my guess is that this memleak failed to free a pointer to some structure, which contents were freed later on
[17:14:04] <sh4rm4> May 06 19:56:57 <sh4rm4> so when the pointer was accessed next, it pointed to garbage
[17:14:04] <sh4rm4> May 06 19:57:05 <sh4rm4> and led to corruption of the game state
[17:14:35] <wjp> what you describe is the _opposite_ of a memory leak
[17:14:45] <wjp> (accessing freed memory)
[17:16:00] <sh4rm4> i cant remember the details
[17:40:23] <wjp> hm, does anyone remember what should make NPCs stop moving when in a cached out area?
[17:40:44] <Dominus> not me :)
[17:40:54] * Dominus is back for a bit just now
[17:52:13] <wjp> hm, Iolo is moving despite being set to dormant
[18:02:26] <wjp> ah, but he's set to non-dormant again almost right away
[20:10:17] --> Malignant_Manor has joined #exult
[20:11:16] <Malignant_Manor> Colourless: Can you please look at this fill mode center crash? https://sourceforge.net/tracker/?func=detail&aid=3157772&group_id=2335&atid=102335
[20:25:49] <wjp> there's suspiciously little actor code actually checking for dormancy
[20:39:24] <Dominus> what causes the sleeping to wake?
[20:40:07] <Dominus> maybe some code got discarded for schedules or we never did it right and Marzo exposed it now
[20:42:03] <Marzo> Considering I don't remember seeing much code checking for dormancy, it is a fair bet that it was never quite finished
[20:44:59] <Dominus> oy, that doesn't bode well then...
[20:51:30] * Dominus plays some more BG for a change - all the bugs he looks at are bad ones - he's rather not looking anymore
[20:53:26] <wjp> Marzo: you removed the check for dormancy in r5750, ironically with a commit message of "Modified NPCs to *really* be dormant when [...]" :-)
[20:54:28] <wjp> it adds more dormant=true; cases, but removes a check for it in Npc_actor::handle_event :-)
[20:56:16] <Marzo> Hm. At the time, I must have thought it
[20:56:27] <Marzo> *that the new checks would do the same work and more
[20:56:53] <Marzo> Does adding back the checks I removed fix the Iolo bug?
[20:57:52] <wjp> yes
[20:58:16] <wjp> but it needs more checking to see if actors don't stay dormant when they shouldn't
[20:58:19] <Marzo> Ah, I see what I did wrong
[21:01:14] <Dominus> malignant, just looked at the forum and realized why you pointed Colourless at that bug :)
[21:01:58] <Dominus> Malignant_Manor: and you are most likely right that this causes that crash
[21:02:54] <Marzo> Lets see: currently, Actor::start, Actor::set_schedule_type, Actor::set_schedule_and_loc and Npc_actor::Paint can awake the character from dormancy
[21:04:33] <wjp> yes
[21:04:48] <wjp> Iolo is woken by ::start, via Patrol_schedule::now_what
[21:05:01] <Marzo> Hm. Maybe this is responsible for the sitting on air bug too
[21:06:21] <Dominus> why that? but I'd be glad if it were
[21:11:03] <Malignant_Manor> There would be no chair to sit on when they tried to sit?
[21:11:57] <Malignant_Manor> That bug was more easily replicated when teleporting.
[21:14:21] <Marzo> The NPC is going to sit on a chair; he gets set to dormant due to a cache out; something incorrectly wakes him up; he tries to sit, but there are no chairs on the now-deleted chunk; if the Sit_actor_action was already ongoing, it will not be notified that the chair was gone (just checked) and it will use a live pointer to now deleted memory; end result: garbage read when trying to sit, incorrect location for sitting action
[21:15:27] <Dominus> I see, sounds logical
[21:15:48] <Dominus> Malignant_Manor: I can't reproduce the resolution crash in the intro
[21:16:35] <Dominus> but I think we got that far last time as well :)
[21:16:55] <Dominus> I just wanted to trap the crash but it wouldn't happen
[21:19:02] <wjp> Marzo: hm, is that a bug in the new object deletion notification system?
[21:19:14] <Marzo> Yes
[21:19:47] <Marzo> It fails to note that (for example) the chair used in the Sit_schedule is passed to Sit_actor_action
[21:22:03] <Marzo> Also, Sit_schedule only sets the chair as a client when the NPC has set on it, not when he finds the chair and is going to sit on it
[21:23:07] <Dominus> Malignant_Manor: great, with my debug build it won't crash but it will with a normal built...
[21:25:42] <Marzo> Anyway, got to go; be back later
[21:29:50] <Dominus> thanks for taking a look
[21:30:42] <-- Marzo has left IRC (Ping timeout: 264 seconds)
[21:39:41] <Dominus> ahhhh, I hate chuckles, I was clicking twice accidently and broke the game....
[21:50:53] <-- shazza has left IRC (Ping timeout: 256 seconds)
[22:00:27] <wjp> yikes, valgrind already hits 1000 errors during startup
[22:01:17] <Dominus> not good
[22:01:40] <wjp> Malignant_Manor: but I fixed the static
[22:01:51] <wjp> will commit in a minute
[22:01:57] <Malignant_Manor> Thanks
[22:02:26] <Malignant_Manor> Yeah, I remember back when I tried Valgrind on Exult just to see how bad it was.
[22:05:04] <-- Baastuul_ has left IRC ()
[22:05:06] <wjp> oh, most (or maybe even all) of them are false positives due to optimized memcpy reading slightly out of bounds
[22:06:02] <Malignant_Manor> I think we still have huge leaks.
[22:07:10] <wjp> these aren't leaks
[22:07:28] <wjp> hm, interesting. Apparently I broke this static myself 2 years ago
[22:10:09] <Dominus> :)
[22:11:17] <Malignant_Manor> A lot of memory gets lost just restoring a save.
[22:11:42] <Malignant_Manor> Just ctrl-r after starting to see it keep climbing up.
[22:31:45] <Dominus> phew britain is really huge. don't remember it being that huge back then :)
[22:32:08] <Dominus> but now I just want to play through as quickly as possible and not enjoy the scenery :)
[22:33:20] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121024073032])
[22:34:50] <wjp> valgrind seems to give useful output for that sitting bug
[22:38:19] <wjp> it's not caused by this earlier schedule/dormancy check
[22:38:36] --> Malignant_Manor has joined #exult
[22:38:43] <Dominus> what is causing it?
[22:38:53] <wjp> well
[22:39:42] <wjp> swap_positions, funnily enough :-)
[22:47:50] <wjp> but I'm unsure if this valgrind warning is related to sitting on the air
[22:48:03] <wjp> having trouble reproducing it
[22:48:33] <Dominus> really? it's happening all the time...
[22:49:10] <Dominus> britain's blue boar at least two displaced ones, and the taverns in SI main land, too
[22:49:20] <wjp> do you have a screenshot?
[22:51:25] <Dominus> trying... now it behaves good of course
[22:53:14] --> Kirben has joined #exult
[22:53:14] --- ChanServ gives channel operator status to Kirben
[22:53:38] <wjp> of course :-)
[22:55:29] <Dominus> wjp, I got it to reproduce but it was clearly a chace-out/in problem. I was sleeping at the monitor inn until 6pm and then people cam ein and sat down
[22:55:34] <Dominus> correctly
[22:55:57] <Dominus> F3 teleported to fawn slept til 8pm, teleported back and they were displaced
[22:56:32] <Dominus> *maybe* it is caused by two different things and it just seems to be one problem :)
[22:56:40] <wjp> do you have a screenshot?
[22:56:50] <Dominus> wjp: I was about to ask if you want one :)
[22:57:14] <Dominus> one moment
[22:57:54] <Dominus> wjp: http://imageshack.us/f/59/monitoru.png/
[22:58:32] <Dominus> when you click on it you get the big one
[22:59:08] <wjp> oh, that's rather obvious indeed
[22:59:26] <wjp> I was hoping that swap_positions in the valgrind log would just have meant they were shifted one spot
[23:02:17] <Dominus> wjp http://imageshack.us/photo/my-images/546/monitor1.png/
[23:02:27] <Dominus> from that savegame in the bug report
[23:03:37] <Dominus> haha, didn't realize he just spoke when I took the shot :)
[23:05:16] <wjp> so that may have been an npc who got swap_positions-ed out of his seat?
[23:07:03] <Dominus> yes, when I reload and do it again I have Andral sitting behind marsten (to the right) and calladin and Standarr standing where shazza is sitting as in the screenshot
[23:07:47] <Dominus> so, yes, I think we have NPCs that get swap positioned in a normal scenario
[23:08:15] <Dominus> but when you teleport to a sitting scene you have the cache-out/in position problem
[23:11:30] <wjp> no valgrind errors there
[23:11:54] <wjp> but I can reproduce that even with the probable schedule/dormancy fix
[23:12:21] <Dominus> the extreme wrong sitting position?
[23:12:46] <wjp> yes
[23:13:00] <wjp> looking at the cheat screen again, the locations are probably their actual schedule locations
[23:13:41] <wjp> i.e., Renfry's schedule is "eat at inn" at 1053,2643
[23:13:47] <wjp> and that's exactly where he ends up
[23:14:10] <wjp> so I'm guessing he is just teleported there when you teleport into the area, but his frame isn't reset
[23:16:14] <Dominus> ah, I understand
[23:18:23] <wjp> and the eat-at-inn schedule won't try and find a seat if the frame is already a sitting one
[23:18:24] <Dominus> I found that a good place is also the Britain inn, as you have really a lot of people sitting there.
[23:18:51] <wjp> I hope this has narrowed it down enough for someone else to fix it :-)
[23:19:05] <Dominus> he he, there is no one else.... :)
[23:19:54] <Dominus> maybe have the schedule recheck whether it is actually sitting *on* a chair :)
[23:20:06] <wjp> :-)
[23:20:25] <Dominus> When you teleport to britian at around 6:50 pm or so and you hit the blue boar you can see it nicely
[23:20:40] <Dominus> they teleport to their spots near the chairs and sit down
[23:21:13] <Dominus> then teleport elsewhere far away, sleep an hour, teleport back and they will sit at their schedule locations
[23:21:25] <wjp> that fits
[23:21:41] <Dominus> nicely debugged
[23:21:46] <wjp> I wonder if we should be smarter about frames, or smarter about initial actions
[23:22:10] <Dominus> probably both
[23:22:24] <wjp> things like sleeping schedules might also be affected interestingly
[23:22:38] <Dominus> yes, I was about to mention that
[23:23:00] <Malignant_Manor> Dominus, you are the lead developer of Exult.
[23:23:22] <Malignant_Manor> You really need to get on the ball and start fixing stuff.
[23:23:28] <Dominus> in the case of the teleporting back it would be good if the actors would sit at the right point and not take walk there *again*
[23:23:35] <Dominus> Malignant_Manor: ha ha
[23:24:04] <Dominus> thanks sourceforge for this shot in the foot :)
[23:24:15] <wjp> Dominus: well, there's no real way to determine what "the right point" is
[23:24:54] <Dominus> yeah, I know. So best would be if frame would be smarter. No chair -> NO SITTING!!!!
[23:25:08] <wjp> of course some heuristic like "already sitting down not too far from the schedule location" might do the trick
[23:25:41] <Dominus> that sounds good too
[23:25:50] <wjp> or maybe even just don't teleport at all if an actor is close to the schedule location
[23:26:43] <Dominus> probably a mix of all those. the actor still shouldn't sit in the air (or sleep on the floor)
[23:29:58] <wjp> but speaking of sleeping...
[23:30:07] <wjp> good night
[23:30:36] --> Dominus1 has joined #exult
[23:30:49] --- ChanServ gives channel operator status to Dominus1
[23:30:49] --- Dominus is now known as Guest87151
[23:30:50] <-- Guest87151 has left IRC (Killed (hobana.freenode.net (Nickname regained by services)))
[23:30:50] --- Dominus1 is now known as Dominus
[23:30:50] <Dominus> haha, didn't see you leave, was disconnected
[23:30:59] <Dominus> good night
[23:31:14] <wjp> was only 10 seconds ago :-)
[23:31:26] <Dominus> oh :)
[23:31:34] <Dominus> going to bed too now