#exult@irc.freenode.net logs for 15 Mar 2010 (GMT)

Archive Today Yesterday Tomorrow
Exult homepage


[01:38:44] --> Malignant_Manor has joined #exult
[02:18:07] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.5.3/20091020102323])
[02:26:25] --> Marzo has joined #exult
[02:27:18] <Marzo> Colourless: I figured out what was causing the midi crash in MinGW, so I'd advise against wasting any more time over it
[02:27:28] <Marzo> (not that I think you still are_
[02:27:37] <Marzo> s/_/)/
[02:28:38] <Marzo> But given the cause, I am surprised the bug has lasted this long -- it should have been happening for years now
[02:28:55] <Marzo> (but then again, most people were probably using the oggs for music...)
[02:31:48] <Marzo> The greatest clue to the solution was the fact that the problem disappeared when you switched to MinGW GCC 4.4
[02:32:26] <Marzo> This version, as well as GCC 4.3, has Dwarf-2 exception handling, whereas older versions of MinGW GCC used SJLJ
[02:33:38] <Marzo> SJLJ (Set Jump/Long Jump) used the stack in a way that wasn't multi-thread-safe unless you compiled with the -mthreads compile option, which was never used in Exult
[02:35:05] <Marzo> Using -mthreads has the disadvantage that the compiled binary has an additional dependency on mingwm10.dll
[02:36:30] <Marzo> The MSVC compiler probably did the "right thing" all along by compiling in a multi-thread-safe way
[02:36:51] <Marzo> And this wasn't an issue on Linux and others because it used Dwarf-2 for a long time
[02:37:59] <Marzo> (MinGW kept SJLJ for so long because it is needed in Windows if you want to throw exceptions across DLL boundaries)
[02:38:10] --> Malignant_Manor has joined #exult
[02:42:22] <Marzo> Malignant_Manor: If you look at the logs, I have just explained what is causing the intro skip crash in some versions of MinGW
[02:42:55] <Malignant_Manor> Colourless thought it was multithreading related like you said.
[02:43:11] <Colourless> Marzo, ah
[02:43:21] <Colourless> thanks for figuring it out :-)
[02:43:34] <Colourless> it was driving me nuts
[02:43:51] <Marzo> (I was particularly lucky in this because I had been hit by a SJLJ-vs-Dwarf2 difference recently)
[02:44:04] <Malignant_Manor> Marzo, I've downloaded the XP symbols, but how do I have GDB use them?
[02:44:26] <Marzo> If they are properly installed, GCC will pick them up automatically
[02:44:56] <Marzo> (IIRC, there was an installer with the symbols which placed them in a subdir of the Windows dir)
[02:45:29] <Marzo> I am now just trying to figure a way to detect the compiler's exception model to automatically add the option if needed
[02:47:57] <Malignant_Manor> I'm still getting a bunch of unknowns http://pastebin.com/qdWEZkKE
[02:49:34] <Marzo> I would wager that these are because you are using a GCC with SJLJ exception model, meaning the stack is corrupted by the exception thrown in a multi-threaded program and GCC cannot find out what is happening
[02:49:42] <Marzo> s/GCC/GDB
[02:57:38] <Colourless> perhaps we should put an #if defined(WIN32) && GCC<V4.3 #error Exception handling is not thread safe or something
[02:58:42] <Colourless> When compiling, -mthreads defines -D_MT
[02:59:24] <Colourless> so should put a check somewhere to make sure if using old versions of GCC that _MT is defined
[02:59:55] <Marzo> I figured out that gcc -v outputs the compile flags of the compiler; this includes --enable-sjlj-exceptions
[03:02:38] <Marzo> Maybe it can be exploited to add the compile flag in Makefile.mingw if needed, with a warning about the additional dependency
[03:04:46] <Marzo> (although I also like the #error idea)
[03:06:18] <Colourless> can probably do some fancy make file macro stuff
[03:07:20] <Marzo> Is there a way to execute a bash command in a makefile?
[03:07:23] <Colourless> $(findstring find,in)
[03:07:23] <Colourless> Searches in for an occurrence of find. If it occurs, the value is find; otherwise, the value is empty. You can use this function in a conditional to test for the presence of a specific substring in a given string. Thus, the two examples,
[03:07:29] <Colourless> marzo yes easy
[03:08:09] <Marzo> The useful command would be gcc -v 2>&1 | grep -io sjlj
[03:08:12] <Colourless> GTK_INCLUDES:=$(shell pkg-config --cflags gtk+-win32-2.0)
[03:08:31] <Marzo> Oh, right; of course, how dumb of me...
[03:08:31] <Colourless> sets GTK_INCLUDES to the result of the shell command
[03:09:32] <Colourless> i think though something like this may be safer $(findstring sjlj, $(shell gcc -v 2>&1))
[03:09:40] <Marzo> Aye
[03:10:24] <Colourless> i'm going off for a bit now
[03:10:27] <Marzo> k
[03:13:53] <Colourless> oh, btw just before i go, my gcc has --disable-sjlj-exceptions
[03:14:03] <Colourless> so you'd need to chec for the entire string --enable-sjlj-exceptions
[03:14:12] <Marzo> That is important to know, yes
[03:15:56] <Colourless> this seems to have the expected result
[03:15:56] <Colourless> USING_SJLJ_EXCEPTIONS:=$(findstring --enable-sjlj-exceptions, $(shell gcc -v 2>&1))
[03:18:34] <Colourless> ifneq ($(USING_SJLJ_EXCEPTIONS),)
[03:18:38] <Colourless> blahblahbkah
[03:18:39] <Colourless> endif
[03:18:52] <Marzo> Aye, written already :-)
[03:18:57] <Marzo> Thanks
[03:19:18] <Colourless> anyway, really off now :-)
[03:20:24] <Marzo> Farewell
[03:25:02] <Malignant_Manor> When you add that, can you add the two patches on this tracker? http://sourceforge.net/tracker/?func=detail&aid=2966927&group_id=2335&atid=102335
[04:46:56] <Marzo> Done
[04:49:57] <Malignant_Manor> Nice, looks like you fixed the unimplemented npc drag.
[04:51:36] <Malignant_Manor> I'll have to test it in a bit.
[04:52:32] <Malignant_Manor> I was just going to close the tracker and add a new one to better describe the remaining problem.
[04:53:05] <Marzo> Be sure to find where mingwm10.dll is and copy it to Windows/System32 or to Exult dir
[04:54:31] <Marzo> (as I think you are using a GCC with SJLJ exceptions)
[04:54:45] <Malignant_Manor> I'll update to 4.5.0 if this seems to work.
[04:55:02] <Marzo> The most recent is 4.4.0 :-)
[04:55:09] <Malignant_Manor> nope
[04:55:54] <Malignant_Manor> Newest proposed is 4.5.0 added 3 days ago.
[04:56:21] <Malignant_Manor> actually one day ago
[04:56:53] <Marzo> That is new
[04:57:04] <Marzo> And it probably won't need that DLL
[04:57:32] <Malignant_Manor> Well, I will test it first.
[04:58:36] <Malignant_Manor> That means 15 or so minutes to compile once my file access frees up.
[05:04:07] <Malignant_Manor> So far it warns me about the safe threading and additional dll.
[05:04:15] <Marzo> As it should
[05:16:37] <Malignant_Manor> compile error on Windnd::DragEnter line 145 case label does not reduce to an integer constant
[05:17:52] <Malignant_Manor> Windnd::Drop line 256, forbidden comparison between pointer and integer
[05:18:19] <Marzo> Change all instances of U7_TARGET_NPCID_NAME to U7_TARGET_NPCID
[05:20:01] <Marzo> I will advise you to hold off a bit because I found a slight inconsistency which will prevent chunks from being dragged now
[05:24:02] <Marzo> Fixes committed
[05:25:19] <Marzo> (to trunk, I mean)
[05:25:44] <Marzo> This one will probably require a full recompile
[05:31:03] <Kirben> Isn't that SJLJ exceptions check in Makefile.mingw in reverse?
[05:33:18] <Malignant_Manor> windrag.cc:258: cannot convert 'Windnd::<anonymous union>' to 'unsigned char*' for argument '1' to 'void Get_u7_npcid(unsigned char*, int&)'
[05:34:06] <Marzo> Nope, I don't think so
[05:34:39] <Marzo> Why? Is it detecting yours as SJLJ and it is Dwarf-2?
[05:35:08] <Kirben> Yes, using GCC 4.2.1.
[05:35:19] <Kirben> Using built-in specs.
[05:35:20] <Kirben> Target: mingw32
[05:35:20] <Kirben> Configured with: ../gcc-4.2.1-2-src/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --program-suffix=-dw2 --with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw --with-local-prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry --disable-sjlj-exceptions --enable-libstdcxx-debug --enable-cxx-flags=-fno-function-secti
[05:35:21] <Kirben> Thread model: win32
[05:35:21] <Kirben> gcc version 4.2.1-dw2 (mingw32-2)
[05:35:38] <Marzo> Malignant_Manor: Replace 'data' by 'wdd.get_data()'
[05:37:28] <Marzo> Kirben: Try replacing line 81 of Makefile.mingw by this: ifeq ($(USING_SJLJ_EXCEPTIONS),$())
[05:37:55] <Malignant_Manor> It compiled
[05:39:14] <Marzo> (I am unable to test in Windows right now, which is the reason for these errors)
[05:39:51] <Malignant_Manor> Yeah, it really sucks not being able to work in the environment you are coding for.
[05:40:38] <Malignant_Manor> Couldn't you just cross compile for the non-MinGW stuff?
[05:41:03] <Marzo> I haven't been able to set up a cross-compiler for Windows yet
[05:41:24] <Marzo> (not that I *really* tried)
[05:41:45] <Malignant_Manor> We're a bit screwed on OSX now.
[05:41:53] <Marzo> Aye
[05:42:49] * Marzo pokes Kirben with the Death Scythe in an attempt to elicit a response
[05:44:25] <Malignant_Manor> What did you do to the trunk?
[05:44:44] <Kirben> Yes, that change seems to work.
[05:45:24] <Malignant_Manor> nvm
[05:45:25] <Marzo> Malignant_Manor: can you try this change too and see if it still detects your compiler as using SJLJ?
[05:45:41] <Malignant_Manor> I copied the makefile from branch like an idiot
[05:48:06] <Malignant_Manor> Yes, it is still detecting it as using SJLJ after the change to line 81.
[05:51:16] <Marzo> Change committed to trunk and branch
[06:02:07] <Malignant_Manor> I can confirm it fixed the intro crash.
[06:02:27] --> julien has joined #exult
[06:09:57] <Malignant_Manor> Npcs 281-284 don't seem to drop
[06:10:12] <Malignant_Manor> in BG
[06:12:28] <Malignant_Manor> NVM, now they are at a different location. Maybe it thought I dropped them on a person.
[06:14:13] <Malignant_Manor> Show Gump doesn't seem to be working on non-npc containers.
[06:45:58] <Malignant_Manor> I got around to looking into it and a fix is here. http://pastebin.com/74q2MirL
[07:07:41] <Marzo> I am working on a more proper fix that also fixes 64-bit
[07:27:09] <Malignant_Manor> What's wrong with 64 bit?
[07:30:44] <Marzo> It was segfaulting because long ago, I had written non-portable code
[07:31:00] <Marzo> (assuming that a pointer was 4-bytes)
[07:31:38] <Marzo> In fact, it is a wonder that ES was actually working on 64-bit as this error was endemic
[07:41:34] <Marzo> Well, I will continue after sleeping
[07:41:37] <Marzo> Good night
[07:46:10] <-- Marzo has left IRC (Ping timeout: 248 seconds)
[07:48:58] <Colourless> pah!
[07:49:11] <Colourless> on my PPC mac, SDL has decided that its a little endian arch
[07:49:31] <Colourless> which completely screws up the audio output
[07:49:55] <Colourless> double checking everything its setting SDL_BYTEORDER to SDL_LIL_ENDIAN
[08:22:10] <Colourless> guessing the macports SDL package don't work for PPC macs
[08:24:11] * Colourless makes a symlink from /opt/local/include/SDL to /Library/Frameworks/SDL.framework/Headers
[08:25:17] <Malignant_Manor> You're the new Mac guy until Dominus gets back.
[08:26:31] <Colourless> bah. i hate macs. only got it for platform testing
[08:27:07] <Malignant_Manor> That's all we need you for.
[08:27:42] <Malignant_Manor> The added plus is the fact that you know coding a whole lot better than Dominus, so no middle man.
[08:38:07] <Malignant_Manor> Wow, looking back at the screen, That's all we need you for. = That's all we need you to do with Macs.
[08:49:45] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158])
[10:25:37] --> shazza has joined #exult
[12:31:14] <-- Rottingbeef has left IRC ()
[12:58:29] <-- Colourless has left IRC (Quit: casts improved invisibility)
[12:58:37] <-- Kirben has left IRC ()
[13:52:21] --> Marzo has joined #exult
[15:00:24] <-- Marzo has left IRC (Ping timeout: 252 seconds)
[15:19:48] <-- shazza has left IRC ()
[20:32:15] --> Rottingbeef has joined #exult
[21:27:55] --> Marzo has joined #exult
[21:42:08] --> Malignant_Manor has joined #exult
[22:11:14] --> Kirben has joined #exult
[22:11:14] --- ChanServ gives channel operator status to Kirben
[22:31:18] --> Colourless has joined #exult
[22:31:18] --- ChanServ gives channel operator status to Colourless
[22:48:49] <Marzo> Colourless: I forgot to mention yesterday, but Dominus reported a bug on OS X
[22:48:53] <Marzo> His words were:
[22:49:00] <Marzo> <Dominus> Marzo, when you are reading this, your merging of Colourless branch fix for always assuming <static> broke OS X
[22:49:05] <Marzo> <Dominus> rev 6269
[22:49:50] <Marzo> As far as I can tell, it should work; not being able to test to see what is wrong makes debugging kind of hard, especially with Dominus gone for the next month
[22:50:30] <Colourless> which branch is broken?
[22:51:03] <Marzo> I would guess both, but he said he was testing trunk IIRC
[22:51:14] <wjp> I would interpret it as working on branch, broken on trunk, but not sure
[22:51:32] <Marzo> Possible
[22:52:07] <Colourless> i'll try compiling and using the trunk later and see what happens.
[22:54:03] <Malignant_Manor> I think gcc 4.5.0 RC is might be crap.
[22:54:19] <Kirben> Getting compile error with current SVN (trunk):
[22:54:20] <Kirben> In file included from actors.cc:78:
[22:54:21] <Kirben> ./server/objserial.h:42: error: 'Serial_out& Serial_out::operator<<(intptr_t)' cannot be overloaded
[22:54:21] <Kirben> ./server/objserial.h:38: error: with 'Serial_out& Serial_out::operator<<(int)'
[22:54:21] <Kirben> ./server/objserial.h:66: error: 'Serial_in& Serial_in::operator<<(intptr_t&)' cannot be overloaded
[22:54:21] <Kirben> ./server/objserial.h:62: error: with 'Serial_in& Serial_in::operator<<(int&)'
[22:54:47] <Marzo> Hm, I should have seen it coming
[22:55:11] <Marzo> But it is safe to delete these two functions, I ended up using the ones with unsigned long anyway; hold a moment
[22:55:13] <Malignant_Manor> I can't compile nomixer. It fails at expack. This may be the experimental gcc though.
[22:55:34] <Malignant_Manor> C:\DOCUME~1\Owner\LOCALS~1\Temp\ccnXBSMe.s: Assembler messages:
[22:55:36] <Malignant_Manor> C:\DOCUME~1\Owner\LOCALS~1\Temp\ccnXBSMe.s:6262: Error: junk at end of line, first unrecognized character is `,'
[22:57:02] <Marzo> gcc 4.5.0 *RC* < There is your problem :-)
[22:57:22] <Malignant_Manor> Yeah, trunk fails too.
[22:57:44] <Marzo> Kirben: you can update from SVN and compile now
[23:05:59] <Kirben> Compiles fine now.
[23:17:39] <-- Kirben has left IRC (Ping timeout: 240 seconds)
[23:55:13] --> Kirben has joined #exult
[23:55:13] --- ChanServ gives channel operator status to Kirben