#exult@irc.freenode.net logs for 24 Oct 2012 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage

[01:28:33] <-- sh4rm4 has left IRC (Ping timeout: 276 seconds)
[01:41:28] --> sh4rm4 has joined #exult
[05:50:37] <-- Kirben has left IRC ()
[07:27:21] <-- sh4rm4 has left IRC (Ping timeout: 276 seconds)
[07:28:51] --> sh4rm4 has joined #exult
[08:38:12] <-- ParuNexus has left IRC (Ping timeout: 248 seconds)
[08:41:40] <-- Rottingbeef has left IRC ()
[09:19:13] --> Dominus1 has joined #exult
[09:19:18] <-- Dominus has left IRC (Read error: Connection reset by peer)
[09:24:32] --> Rottingbeef has joined #exult
[09:26:08] --- ChanServ gives channel operator status to Dominus1
[09:26:08] --- Dominus1 is now known as Dominus
[09:27:34] --> ParuNexus has joined #exult
[09:35:39] <-- Rottingbeef has left IRC (Ping timeout: 260 seconds)
[09:40:37] --> Rottingbeef has joined #exult
[09:44:56] <-- Rottingbeef has left IRC (Ping timeout: 255 seconds)
[09:49:05] --> Rottingbeef has joined #exult
[10:07:06] <-- Marzo has left IRC (Ping timeout: 240 seconds)
[12:04:00] <Dominus> hmm, gotta ask marzo what is up with combat and pathfinding to enemy bats. when I looked at that firefield problem I ran into a freezing Exult again and when I killed it I got the "Danger! Danger! Object being placed before itself." message Marzo added in rev 7112
[12:05:19] <wjp> eek
[12:05:39] <wjp> dare I hope it's reproducable?
[12:05:55] <Dominus> yes, kind of
[12:06:08] <Dominus> same thing as happened some time ago
[12:06:56] <Dominus> let me look for the coordinates
[12:09:09] <wjp> if so, a stack trace from a debugger there would be really great
[12:09:26] <Dominus> I'll make a proper report later, right now got to run and my gf will kill me when she sees I'm "playing" again instead of working :)
[12:09:35] <wjp> ok :-)
[12:13:19] --> TheCycoONE has joined #exult
[13:14:12] --> Marzo has joined #exult
[13:37:27] <Dominus> marzo, I'm not really here and I need to make a proper test case but I ran into your "danger..." message from rev 7112 (see logs). later today/night I'll make a proper test case
[15:15:18] --> Marzo1 has joined #exult
[15:15:18] <-- Marzo has left IRC (Disconnected by services)
[15:17:38] --> Marzo has joined #exult
[15:17:56] <-- Marzo1 has left IRC (Remote host closed the connection)
[15:30:00] <-- Marzo has left IRC (Remote host closed the connection)
[15:30:13] --> Marzo has joined #exult
[15:47:10] <-- Marzo has left IRC (Ping timeout: 246 seconds)
[15:48:47] --> Marzo has joined #exult
[16:22:52] <-- Marzo has left IRC (Ping timeout: 244 seconds)
[16:36:41] --> Marzo has joined #exult
[16:53:34] <-- Marzo has left IRC (Ping timeout: 240 seconds)
[17:09:44] --> Marzo has joined #exult
[17:25:14] <-- Marzo has left IRC (Ping timeout: 272 seconds)
[17:42:11] --> Marzo has joined #exult
[17:55:37] <-- Marzo has left IRC (Ping timeout: 255 seconds)
[18:06:06] --> Marzo has joined #exult
[18:09:02] <-- Marzo has left IRC (Read error: Connection reset by peer)
[18:10:16] --> Marzo has joined #exult
[18:23:18] <-- Marzo has left IRC (Ping timeout: 245 seconds)
[19:33:33] <Dominus> hmm, couldn't reproduce this now and the savegame I had is gone :(
[19:33:51] <Dominus> instead I realized how stupid the companions are
[19:33:54] <Dominus> really
[19:34:42] <Dominus> "oh, it's getting warm!" "hmm, I'm standing on a fire field" "hmm, I'm burning!" "oh well, I'll wait till the flames ... aarrgh!"
[19:40:22] <Dominus> grr. I had this happen almost every time and now can't reproduce
[19:47:11] <wjp> if you're trying, it would be good to do so in a debugger with a breakpoint on the "danger" line
[19:47:20] <Dominus> he he
[19:47:33] <Dominus> I thought I'd first find a way to trigger it :)
[19:47:58] <wjp> yeah, but then you'll see that it refuses to happen in a debugger :-)
[19:48:09] <wjp> (Murphy...)
[19:49:31] * Dominus grummls... murphy....
[19:49:47] <Dominus> how do I add a breakpoint?
[19:49:58] <Dominus> but I'm not going to try further tonight
[19:50:03] <wjp> actually it's probably easier to put an assert(false); right below the danger output
[19:51:03] <wjp> then when you run it in gdb it will automatically break there
[19:52:22] <Dominus> oh that file is used by a lot...
[19:52:37] <wjp> it's a header?
[19:52:46] <Dominus> yeah, objlist.h
[19:52:56] <wjp> ah...
[19:53:57] <Dominus> hah!!!!!!
[19:54:12] <Dominus> first try and got it
[19:54:29] <wjp> heh, talk about luck :-)
[19:54:35] <Dominus> wjp, can you give me a hand? so it froze, what now?
[19:54:39] <Dominus> in gdb
[19:54:44] <wjp> first 'bt'
[19:55:22] <Dominus> do i kill it first?
[19:55:27] <wjp> no
[19:55:37] <wjp> you should have a gdb prompt now
[19:56:02] <wjp> oh, um, did you run it in gdb?
[19:56:29] <Dominus> maybe I did it wrong. gdb exult and then run
[19:56:55] <wjp> ok
[19:57:35] <Dominus> in terminal it shows me the Danger! Danger ! line but I don't have the gdb prompt
[19:57:55] <Dominus> I was able to type bt and hit enter but nothing happens
[19:57:56] <wjp> um, weird
[19:58:07] <wjp> that it continued
[19:58:16] <wjp> that assert should've killed it
[19:58:44] <Dominus> std::cerr << "Danger! Danger! Object list modified while being iterated." << std::endl;
[19:58:44] <Dominus> assert(false);
[19:58:52] <Dominus> is what I entered
[19:59:26] <Dominus> and I'm using apple gdb, perhaps it doesn't function properly
[20:00:08] <wjp> even if gdb didn't work, it should've killed exult :/
[20:00:25] <Dominus> so should I kill the exult task anyway?
[20:00:29] <wjp> of course asserts can be disabled in various ways, but I don't think we did
[20:00:44] <wjp> yeah, once it's in the infinite loop it's too late to see anything :/
[20:01:25] <wjp> try abort(); instead of the assert(false);
[20:01:41] <wjp> that's a bit less conditional :-)
[20:01:53] <Dominus> http://pastebin.com/2eB9qztK is the bt I got after killing it
[20:01:54] <wjp> oh, maybe try right on startup somewhere to ensure it really does trap
[20:02:28] <Dominus> right on startup?
[20:02:38] <wjp> where you migrate the config for example
[20:02:47] <wjp> just to test if the abort() really breaks into gdb
[20:02:56] <Dominus> ah. ok :)
[20:04:26] <Dominus> ok, there it aborted :)
[20:06:10] <Dominus> hmmm
[20:06:28] <Dominus> got it to trigger again but it still loops and didn't abort
[20:07:28] <wjp> ah, there are actually two of those Danger messages I see
[20:07:36] <Dominus> *noooooo*
[20:08:08] <wjp> (same file)
[20:08:44] * Dominus makes
[20:11:31] <Dominus> now it won't trigger :(
[20:14:13] <Dominus> wjp, got it now!!!
[20:14:57] <Dominus> bt http://pastebin.com/yv9PgK57
[20:17:01] <wjp> hm, compiled with only very limited debug info :-(
[20:17:36] <Dominus> hmm, yeah... sorry... will need to recompile completely then. didn't think of that
[20:17:57] <Dominus> got to run now. I'll see about making a better bt later
[20:18:07] <wjp> but this is enough to have the basics at least :-)
[20:18:08] <wjp> thanks!
[20:18:14] <wjp> and good night
[20:21:24] <sh4rm4> <wjp> actually it's probably easier to put an assert(false); right below the danger output
[20:21:34] <sh4rm4> better __asm__("int3");
[20:21:44] <sh4rm4> or signal(getpid(), SIGTRAP);
[20:21:58] --- Sevalecan is now known as n00bsaibot
[20:22:30] <sh4rm4> for completeness sake, you set a breakpoint like : bp myfile.cc:42
[20:22:36] <sh4rm4> where 42 is the line number
[20:22:54] <wjp> I'm going to go out on a limb here and suggest that abort() is significantly simpler :-)
[20:22:59] <sh4rm4> s/signal/kill/
[20:23:31] <sh4rm4> abort doesn't stop there directly unfortunately
[20:23:40] <sh4rm4> it'll call a glibc function
[20:23:46] <wjp> that's what stack frames are for
[20:23:49] <sh4rm4> so you dont have access to the local variables
[20:23:55] <wjp> of course you do
[20:24:02] <wjp> just select the right frame
[20:24:12] <sh4rm4> so how do you get back to the last stack ?
[20:24:20] <wjp> up, or frame #
[20:24:37] <sh4rm4> where to get the number from ?
[20:24:50] <wjp> front of the line in the bt
[20:25:12] <sh4rm4> ah, good to know
[20:26:32] <wjp> (or repeat 'up' until you get there. 'down' to go back)
[20:27:24] * Dominus is back and will do a recompile now
[20:27:35] <TheCycoONE> speaking of gdb, ddd is really fancy
[20:27:50] <wjp> hm, I think I suggested a bunch of map-related extra debugging statements at some point
[20:27:59] <wjp> let's see if I can still find those
[20:30:27] <wjp> but it looks like this is still the same issue we hit back then :-(
[20:30:40] <wjp> so I guess these schedule changes didn't fix it :/
[20:30:56] <Dominus> :/
[20:31:01] <Dominus> it's those damn bats
[20:31:13] <wjp> last time it was Sentri I think :-)
[20:31:35] <Dominus> he's part of the party again
[20:32:02] <Dominus> ./configure --disable-sdltest --disable-oggtest --disable-vorbistest --disable-alsa --disable-fluidsynth --disable-tools --enable-heavy-gdb-debug --disable-all-hq-scalers
[20:32:05] <sh4rm4> yeah, it looks like it is what happened to me while running around in dungeon despise
[20:32:11] <sh4rm4> http://sourceforge.net/tracker/?func=detail&aid=3436194&group_id=2335&atid=102335
[20:32:43] <Dominus> I'm using one of your savegames
[20:33:50] * wjp ponders
[20:34:51] <Dominus> new bt http://pastebin.com/HYNs5BGH
[20:35:29] <sh4rm4> now you need to go "up"
[20:35:37] <wjp> did you do a 'make install' maybe?
[20:35:44] <Dominus> no
[20:35:55] <wjp> I wonder where all the debugging info went :-(
[20:36:56] * wjp is reading through old logs, in the meantime
[20:37:18] <wjp> it looks like we hit this back on 2010-12-14
[20:37:24] <Dominus> hmm, does adding debug/trace/combat/yes help?
[20:38:32] <sh4rm4> what's the shapeid ?
[20:39:24] <wjp> if this is identical to last time, what's happening is that a chunk's first_nonflat is not actually in that chunk
[20:39:59] <sh4rm4> wjp, now he needs to enter: "frame 3", correct ?
[20:40:30] <wjp> yes, but there's no debugging info, so not much to see
[20:40:55] <Dominus> wjp, I'm pretty sure it's very similar to what happened last time
[20:40:58] <sh4rm4> why ? the symbol names of the functions are there
[20:41:04] <wjp> so the question is where we're making an actor move chunk without updating that
[20:41:09] <sh4rm4> so the symbol names of the data should be there as well
[20:41:56] <wjp> there would be line numbers and function parameters if it had full debug info
[20:42:23] <Dominus> hmm, I wonder why it doesn't have that
[20:42:58] <sh4rm4> maybe strip is used ?
[20:43:00] <Dominus> let me see if I can "quickly" get a real gdb
[20:43:06] <Dominus> no strip used
[20:43:43] <sh4rm4> did you run gdb ./exult or gdb exult ?
[20:43:57] <Dominus> gdb exult
[20:44:09] <Dominus> and it used the freshly built exult
[20:44:13] <sh4rm4> in the latter case you would have debugged the installed binary, not the freshly compiled one
[20:44:29] <Dominus> I have no exult installed
[20:44:42] <wjp> any installed versions wouldn't have those aborts
[20:44:57] <TheCycoONE> it seems more like the compile flags are getting overridden
[20:45:07] <wjp> yes
[20:45:14] <sh4rm4> indeed
[20:45:27] <Dominus> grrr
[20:45:31] <Dominus> indeed they are
[20:47:16] * Dominus slaps himself around with a big -O2
[20:47:22] <TheCycoONE> well that solves those mysteries. Was enjoying the read
[20:47:27] <TheCycoONE> -Og will be nice
[20:47:28] <Dominus> :)
[20:49:15] <Eviltar_> go all gentoo on it with some -Ofast -funroll-loops -fomit-frame-pointer
[20:49:38] <Eviltar_> -ffast-math
[20:52:57] <Dominus> hmm, I'm sure I didn't accidently override it again but here we go again http://pastebin.com/M0vv7TRm
[20:53:47] <Dominus> it's being made with clang. could that be a problem?
[20:54:26] <sh4rm4> look at the clang invocations
[20:54:32] <sh4rm4> does it have -O0 -g inside ?
[20:54:59] <sh4rm4> if it doesnt, it's pointless to try to debug
[20:55:12] <Dominus> it has -O0 not -g
[20:55:25] <sh4rm4> -g is the debug info
[20:55:43] <sh4rm4> -O0 is "no optimization", making debugging a ton simpler
[20:56:00] <wjp> is there a -ggdb3 in there?
[20:56:17] <wjp> if so, try replacing the heavy debug option with just --enable-debug
[20:57:19] <Dominus> yes, the -ggdb3 is there
[20:57:22] <sh4rm4> CXXFLAGS="-O0 -g" ./configure ... should do the job as well
[20:57:36] <wjp> I suppose clang just doesn't recognize that
[20:58:41] <sh4rm4> i never seen a real difference in debug info quality with everything beyond -g
[21:00:41] <wjp> Dominus: could you add a bunch of new asserts?
[21:01:01] <Dominus> of course
[21:01:30] <wjp> last line of Map_chunk::remove in objs/chunks.cc:
[21:01:30] <wjp> assert(!first_nonflat || first_nonflat->chunk == this);
[21:02:20] <wjp> first line of Map_chunk::add, same file:
[21:02:20] <wjp> assert(!newobj->chunk);
[21:02:20] <wjp> assert(!first_nonflat || first_nonflat->chunk == this);
[21:05:08] <Dominus> map_chunk::add very first line before the ( or after?
[21:06:01] <wjp> right before newobj->chunk = this;
[21:07:18] <sh4rm4> https://github.com/rofl0r/exult/blob/master/objs/chunks.cc#L837
[21:08:32] <Dominus> wjp, hopefully a more informative bt http://pastebin.com/GkM58e0j
[21:09:14] <wjp> yup, much better :-)
[21:09:46] <wjp> let's see
[21:09:56] <Dominus> (I'm sure it is iolo again, he's just not into bats)
[21:10:08] <wjp> try this:
[21:10:11] <wjp> frame 4
[21:10:21] <wjp> print first_nonflat->chunk
[21:10:33] <wjp> print first_nonflat
[21:10:35] <wjp> print this
[21:10:36] <wjp> print newobj
[21:11:15] <Dominus> #4 0x000000010027e1ee in Map_chunk::add (this=0x1024133d0, newobj=0x1086d5f00) at chunks.cc:838
[21:11:16] <Dominus> 838 assert(!first_nonflat || first_nonflat->chunk == this);
[21:11:16] <Dominus> Current language: auto; currently c++
[21:11:16] <Dominus> (gdb) print first_nonflat->chunk
[21:11:16] <Dominus> $1 = (Map_chunk *) 0x0
[21:11:16] <Dominus> (gdb) print first_nonflat
[21:11:16] <Dominus> $2 = (Game_object *) 0x1086d5f00
[21:11:17] <Dominus> (gdb) print this
[21:11:17] <Dominus> $3 = (Map_chunk *) 0x1024133d0
[21:11:18] <Dominus> (gdb) print newobj
[21:11:18] <Dominus> $4 = (Game_object *) 0x1086d5f00
[21:11:55] <wjp> right
[21:12:13] <wjp> debugging statement time...
[21:12:34] <-- TheCycoONE has left IRC (Quit: And then there were n-1)
[21:12:55] <Dominus> ?
[21:13:31] * wjp ponders
[21:14:37] <wjp> I don't quite see why this assert in add() is triggered before the one in remove()
[21:15:08] <sh4rm4> Dominus, "p *newobj"
[21:15:16] <sh4rm4> should dump the entire object
[21:15:31] <sh4rm4> i'd be interested if it has the same shapeid as in my bug report
[21:16:01] <Dominus> http://pastebin.com/T8BFPjKE
[21:16:31] <sh4rm4> thanks
[21:16:36] <sh4rm4> yes, it is 462 again
[21:16:53] <wjp> Sentry
[21:16:55] <sh4rm4> "Usecode 493 not found."
[21:16:59] <sh4rm4> ^ is that normal ?
[21:17:32] <wjp> Dominus: one more assert, first line of Actor::movef in actors.cc
[21:17:40] <wjp> (so before the if (old_chunk))
[21:17:54] <wjp> assert(old_chunk == chunk);
[21:18:25] <wjp> and let's add some more...
[21:18:46] <Dominus> yes, please before I try to trigger it again :)
[21:19:15] <wjp> in Map_chunk::add again, right before those new asserts:
[21:20:22] <wjp> if (newobj->get_shapenum() == 462) fprintf(stderr, "Adding 462 to chunk %p", (void*)this)
[21:20:48] <wjp> and at the top of Map_chunk::remove (so right before the if (cache) )
[21:21:00] <wjp> if (newobj->get_shapenum() == 462) fprintf(stderr, "Removing 462 from chunk %p", (void*)this);
[21:21:09] <wjp> (oh, missed a semicolon in the previous one)
[21:21:32] <wjp> oh, and newobj->get_shapenum should've been remove->get_shapenum in the second one
[21:21:37] * wjp is almost awake
[21:22:04] <wjp> let's go with that
[21:22:34] <Dominus> ok, got it trying to trigger
[21:26:55] <sh4rm4> wjp, what about the usecode not found error message ?
[21:28:03] <wjp> I expect that happens when you double click something unusable, but I really don't remember
[21:29:32] <wjp> oh, oops forgot some \n's after those fprintf
[21:29:39] <Dominus> ah, yeah probably me hclicking on the monster egg
[21:29:52] <Dominus> wjp, where what?
[21:30:03] <Dominus> I couldn't trigger it right now anyway
[21:30:26] <wjp> change %p into %p\n in those two fprintf lines
[21:31:06] <wjp> which savegame are you using, by the way? We can try to multi-task on trying to trigger it :-)
[21:34:01] <Dominus> https://dl.dropbox.com/u/7737184/exult07bg.sav
[21:34:17] <Dominus> (named trigger bats)
[21:34:47] <Dominus> go into the cave, hug the north wall, continue west until you meet the bats and hit c
[21:36:48] <Dominus> phew got it again
[21:37:01] <wjp> just now got it too :-)
[21:37:06] <wjp> the old_chunk == chunk one?
[21:37:21] <Dominus> yes
[21:38:10] <Dominus> do you need my bt?
[21:38:20] <wjp> no, just the fact that it triggers this one is enough
[21:38:26] <Dominus> k
[21:38:49] <wjp> that means that in the middle of processing the chunk change for a single step, something _else_ also changed the chunk
[21:39:20] <wjp> but it had stored the old_chunk previously, and then tries to remove the actor from the old_chunk
[21:39:32] <wjp> but the actor is no longer in that old_chunk because something moved it, and things break
[21:40:04] <Dominus> that even make sense to me :)
[21:40:17] <wjp> so the questions are: what's moving the actor, and should it be allowed to...
[21:40:58] <Dominus> hmm, how do we get that answer?
[21:43:10] <wjp> interestingly Main_actor has very similar code to Npc_actor, but it doesn't store this old_chunk right at the beginning of the step
[21:50:40] <Dominus> hmm, wjp, in my gdb 462 (sentri) was moving a lot, all it showed was mostly added to chunk, removed from chunk... and it froze with him facing the north wall
[21:51:00] <Dominus> could it be he is constantly running against the wall and bouncing back?
[21:51:15] <Dominus> (not really but imaginary)
[21:51:49] <Dominus> Adding 462 to chunk 0x10a667970
[21:51:49] <Dominus> Removing 462 from chunk 0x10a667970
[21:53:51] <Dominus> chunks # stay the same for a long time and then change. almost right before the crash it changed the chunk again (Adding 462 to chunk 0x10a646ce0, removing, adding, dupre approaching...)
[21:54:12] <Dominus> maybe the problem is with dupre trying to take his chunk right then
[21:57:54] <wjp> apparently it's is_blocked()??
[21:59:54] <Dominus> that sounds like my idea that another npc is stepping right into the chunk where sentri is bouncing to and from...
[22:00:23] <wjp> anyway, regardless of the exact cause, the fix is likely making this match Main_actor and not getting old_chunk quite so soon
[22:01:28] <-- Rottingbeef has left IRC ()
[22:04:31] <Dominus> wjp, another savegame, easier to trigger https://sourceforge.net/tracker/?func=detail&aid=3306112&group_id=2335&atid=102335
[22:04:57] <Dominus> it crashes also at old_chunk == chunk
[22:05:17] <Dominus> I just remembered that bug report and thought it might be the same
[22:05:36] <Dominus> you just need to go south and walk through the wood parts through the swamp
[22:07:35] <wjp> eek, that savegame actually crashes exult here when I select it in the load menu
[22:08:09] <Dominus> hmmm
[22:09:03] <Dominus> I can make you another one I bet :)
[22:11:18] <wjp> but if you want to test if that hang is gone for you, try moving Map_chunk *olist = get_chunk();
[22:11:28] <wjp> in Npc_actor::step in actors.cc
[22:11:47] <wjp> down to right above the movef(olist, nlist, tx, ty, frame, t.tz); line
[22:13:05] <wjp> aaah, it's is_really_blocked
[22:13:24] <wjp> that tries to let people move_aside
[22:13:49] <wjp> and that can trigger a swap_positions
[22:13:58] <wjp> so that solves that :-)
[22:16:21] <wjp> wow, that savegame is _really_ crashing
[22:16:26] <Dominus> if it were easy to be sure that I just don't trigger it or whether it really is fixed...
[22:16:41] <wjp> I'm pretty sure :-)
[22:17:33] <wjp> broken party members in there?
[22:18:35] <sh4rm4> how about putting these debug assertions into the trunk ?
[22:18:55] <Dominus> wjp, maybe I think marzo had problems with that save as well
[22:20:12] <sh4rm4> (only enabled in debug builds)
[22:20:14] <Dominus> wjp, https://dl.dropbox.com/u/7737184/exult07bg.sav again, this time it should be at that swamp spot
[22:21:58] <Dominus> wjp, so if that is the real fix, what about the fix we put in two years ago?
[22:22:59] <wjp> which fix?
[22:24:21] <wjp> sh4rm4: I'll add the one which in hindsight would be the logical one :-)
[22:27:01] <Dominus> wjp https://sourceforge.net/tracker/?func=detail&aid=3131920&group_id=2335&atid=102335
[22:27:30] <Dominus> rev 6797
[22:28:06] <Dominus> probably fine, it seems that masked the loop
[22:30:34] <wjp> hm, I don't know
[22:30:53] <wjp> I'm not familiar enough with this code to judge if that would've been a separate bug
[22:32:11] <wjp> anyway, committed
[22:34:31] <Dominus> thanks a lot wjp, that's been a hell of a debug ride :)
[22:35:11] <wjp> only took 22 months :-)
[22:35:31] <wjp> thanks for the help
[22:35:48] <Dominus> :)
[22:36:06] <sh4rm4> and thanks Dominus for your determination to solve it :)
[22:36:20] <wjp> could you test if it still builds with r7147?
[22:36:38] <wjp> (r7146 was the fix, r7147 is an attempt to get it to build with multiple zlib version...)
[22:37:00] <wjp> (since it refuses to build for me without that last change)
[22:37:42] <Dominus> ...building...
[22:37:52] <sh4rm4> zlib had API changes ?
[22:38:16] <Dominus> I haven't even noticed that there was a new zlib version this decade...
[22:38:29] <Dominus> sh4rm4: thanks for your savegames :)
[22:38:50] <wjp> the unzip library we use on top of zlib used some internal symbols from zlib that changed
[22:38:58] <sh4rm4> :)
[22:39:08] <sh4rm4> oh
[22:39:38] <wjp> or I should say preprocessor defines; not symbols
[22:40:44] <sh4rm4> in other words, macros
[22:40:58] <wjp> yes
[22:44:10] <Dominus> yay, only 91 bugs left and only 1 from sh4rm4
[22:44:47] <sh4rm4> which one ?
[22:44:54] <Dominus> sitting int he air
[22:44:59] <sh4rm4> ah
[22:45:02] <sh4rm4> :)
[22:46:14] <wjp> (did the build finish ok?)
[22:46:56] <Dominus> yes, at least for 64bit, still building the other arches :)
[22:47:21] <wjp> ok, great
[22:47:27] <Dominus> just succeeded all arches. good
[22:47:34] <wjp> bedtime then :-)
[22:47:39] <wjp> good night
[22:47:41] <Dominus> YES!
[22:47:45] <Dominus> good night
[22:51:46] <sh4rm4> wow... my build got stuck
[22:51:54] <sh4rm4> mv -f .deps/BilinearScalerInternal_X2Y24.Tpo .deps/BilinearScalerInternal_X2Y24.Plo
[22:51:54] <sh4rm4> mv -f .deps/scale_hq2x.Tpo .deps/scale_hq2x.Plo
[22:51:54] <sh4rm4> ^Cmake[2]: *** [scale_hq3x.lo] Error 1
[22:52:07] <sh4rm4> the c++ compiler was using 14 GB RAM
[22:52:22] <sh4rm4> causing my 16GB equipped machine to swap to death
[22:52:38] <Dominus> hq compiling does use a lot of ram but 14GB is a bit too much
[22:54:13] <sh4rm4> i was using make -j9
[22:54:18] <sh4rm4> to use all 8 cores
[22:54:34] <sh4rm4> one gcc process was consuming 8 GB, another one 6GB
[22:55:04] <Dominus> so maybe that isn't the best way to build exult :)
[22:55:09] <Dominus> anyway, good night
[22:55:17] <sh4rm4> good night
[23:45:39] <sh4rm4> /dev/shm/exult[master]$ la exult
[23:45:40] <sh4rm4> -rwxr-xr-x 1 rofl users 883534716 Oct 25 01:00 exult
[23:45:50] <sh4rm4> yeah, the exult binary is 800 megs