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

Archive Today Yesterday Tomorrow
Exult homepage

[00:15:16] --> shazza has joined #exult
[00:19:26] --> Colourless has joined #exult
[00:19:26] --- ChanServ gives channel operator status to Colourless
[00:23:31] --> shazza` has joined #exult
[00:32:23] <Marzo> Hi Colourless
[00:33:11] <Marzo> I have a bug report for you, whose solution has eluded me for several hours already
[00:34:53] <Marzo> It affects the MT32Emu midi driver -- and apparently, only it is affected
[00:35:43] <Marzo> (but there may be a possibility that Timidity is also affected, I don't know -- would ahve to install Timidity and recompile to be sure)
[00:37:14] <Marzo> Basically, if I start Exult with the midi audio driver set to MT32Emu, Exult will hang forever at LowLevelMidiDriver::loadTimbreLibrary
[00:37:24] <Marzo> Specifically, line 11886
[00:37:34] <Marzo> s/11886/1186/
[00:38:17] <Marzo> However, if I start in any other midi driver I tried thus far, then switch to MT32Emu, everything works fine
[00:47:55] <Marzo> I *think* it may be because MT32Emu uses initSoftwareSynth instead of initThreadedSynth, but I am not sure
[01:18:46] <Colourless> hm
[01:18:53] <Colourless> i'll look into it
[02:11:55] <Colourless> ok i know what the problem with the code it
[02:11:57] <Colourless> *is
[02:36:32] <Colourless> its a threading deadlock
[02:53:03] <Marzo> One thing I found that seemed to 'fix' the issue -- probably by screwing up something else -- was to always call initThreadedSynth in lines 199-200, also calling initSoftwareSynth if isSampleProducer
[02:53:38] <Marzo> Then call destroyThreadedSynth instead of destroySoftwareSynth in line 225
[02:53:47] <Marzo> (in all cases, in LowLevelMidiDriver.cpp)
[02:54:18] <Marzo> It is a quick hack, yes; with untold side effects which I haven't tried to figure out yet, as there is probably a better solution
[03:04:49] <Marzo> Out of curiosity (and owing in part due to the fact that I couldn't find it) -- where exactly are the threads created for SoftwareSynth? I know they exist because GDB says they are being created, but haven't found out where they are created yet
[03:11:59] <-- shazza has left IRC ()
[03:11:59] <-- shazza` has left IRC ()
[03:12:00] <Colourless> SDL is creating them
[03:14:11] <Marzo> Hm; this definitely means then that there is no thread being created for software synth audio
[03:16:12] <Marzo> With the 'hack' I posted about earlier (always calling initThreadedSynth), GDB reports the creation of 3 threads (and one destroyed) before Exult tries to open the midi driver; that last thread is not created in the clean branch code, though
[03:17:48] <Marzo> The odd thing is that the main trunk works, and there is no change in this code
[03:18:56] <Colourless> committed fix for the problem
[03:19:00] <Colourless> well committing
[03:19:13] <Colourless> done
[03:20:38] <Marzo> Compiling...
[03:22:48] <Marzo> Working perfectly
[03:23:53] <Colourless> putting the mt32 roms in the application bundle has some strange side effects
[03:24:06] <Marzo> Now all that remains for MT32 & MT32Emu is to skip loading all the unnecessary timbres and patches
[03:24:23] <Marzo> I committed a possible fix for that
[03:24:30] <Colourless> mt32 emu writes out cached waveform data into the dir where the roms are
[03:24:40] <Marzo> Hm. That is bad
[03:24:51] <Marzo> (so no, I didn't commit a fix for that)
[03:25:20] <Colourless> shoudl edit mt32 emu itself to look in the bundle path for its files, rather than set its base path to it
[03:25:29] <Colourless> should be reasonably easy to fix i think
[03:25:44] <Marzo> Yes, I was doing a quick hack that ended up not working
[03:26:02] <Marzo> Will do it the right way now...
[03:32:16] --> Malignant_Manor has joined #exult
[03:42:28] * Colourless scratches head
[03:43:09] <Colourless> sometimes... only sometimes, exult is crashing because ExultDataSource mouse_data(MAINSHP_FLX, PATCH_MAINSHP, 19); is failing to load anything
[03:44:36] <Marzo> That is odd
[03:46:03] <Colourless> hmm.
[03:46:23] <Colourless> something is causing U7FileManager::file_list to become corrupted
[03:47:07] <Marzo> That is probably my code :-)
[03:47:38] <Colourless> entry 4 in the list this
[03:47:39] <Colourless> ({name=0x06256ed8 "ýýýý««««««««îþîþ" index=-1 ownstr=false },0x061f48c0 {_file={...} })
[03:50:57] <Colourless> my guess, a string is being deleted or something when its in the file_list
[03:51:04] <Marzo> This is probably some misbehaved call to a U7object or U7multiobject that passes a c_str()
[03:51:24] <Marzo> Let me check
[03:54:06] <Marzo> Ah, found them
[03:54:18] <Marzo> Recent mistakes, even
[03:55:29] <Marzo> They are both in audio/Midi.cc: lines 171 and 173
[03:56:05] <Marzo> the correct form would be to pass the flex strings like `File_spec(flex)`
[03:56:55] <Colourless> that would explain why i wasn't getting crashes when using oggs :)
[03:57:23] <Marzo> (I should have known better than to make this mistake, considering I wrote the File_spec class and explicitly disallowed implicit conversion from strings because it caused a similar issue)
[03:57:49] <Marzo> I will finish up the path settings in MT32Emu and commit
[03:57:57] <Colourless> ok thanks
[04:03:52] --> julien- has joined #exult
[04:04:11] <-- julien has left IRC (Ping timeout: 265 seconds)
[04:19:28] --> matt_o has joined #exult
[04:23:07] <-- jvlee has left #exult
[04:25:34] <Marzo> Committed to head, merging to no-SDL branch now
[04:25:43] <Colourless> ok
[04:26:24] <Marzo> And it should be in the branch too now
[04:26:25] --> jvlee has joined #exult
[04:26:57] <Colourless> coolies
[04:29:37] <Colourless> what you'd done looks good
[04:31:15] <Marzo> Whoever it was that added those property overrides for file open/close deserves some praise; it does exactly what is needed
[04:54:26] <Colourless> hhm
[04:54:55] <Colourless> setup_data_dir looks a littlr broken.
[04:55:19] <Colourless> the value of the data_path arguement is never used
[04:55:39] <Colourless> the data_path argument being the value of "config/disk/data_path" in exult.cfg
[04:56:06] <Colourless> looks like line 784 of utils.cc should probably be
[04:56:10] <Colourless> add_system_path("<DATA>", data_path);
[04:56:53] <Colourless> at the moment that code is attempting to use the current dir as the datapath which will almost certainly never be true
[04:57:44] <Marzo> That is correct: line 784 *and* line 788 should both be data_path instead of data
[04:58:54] <Marzo> It was working in the end if you didn't have anything in the cfg, which is where all of the testing went
[04:59:03] <Marzo> Nice catch :-)
[04:59:24] <Colourless> trying to run multiple copies of exult with a single cfg and data dir
[04:59:30] <Colourless> not working :-)
[05:00:11] <Marzo> Hehe
[05:02:55] <Marzo> Fix committed to main trunk, should be in the branch shortly too
[05:05:22] <Colourless> thanks
[05:06:42] <Marzo> If you have a Mac, and are using an app bundle, you can also try putting the BG and SI static dirs in a subdir of (bundle)/Content/Resources/data (IIRC) and setting the appropriate <static_path> in Exult.cfg to <BUNDLE>/subdirname
[05:08:57] <Marzo> (we won't be distributing any such bundles, of course, but it can still be useful for putting in iPhones and other things)
[05:09:27] <Marzo> (not that I think Exult *runs* on an iPhone...)
[05:14:59] <Malignant_Manor> Exult seems to crash in the game menus when clicking while the speech is going on (trunk and branch).
[05:19:27] <Marzo> Can you give a sure-fire way to reproduce it?
[05:22:15] <Malignant_Manor> I can repeat it each time, if I wait until the speech starts in the intro and then click. This is in XP.
[05:24:23] <Marzo> In Ubuntu, there is no crash
[05:24:33] <Marzo> In XP, it will take me a couple of hours to test
[05:24:45] <Marzo> So I will leave for after I sleep
[05:26:36] <Marzo> (by the way, I did some benchmarking -- starting from clean svn, my Ubuntu box configures, compiles and cleans Exult, ES and tools 7 times in the time my Windows box takes to compile once)
[05:28:50] <Marzo> In any event, I am off to bed -- good night
[05:29:51] <Malignant_Manor> good night
[05:35:32] <-- Marzo has left IRC (Ping timeout: 265 seconds)
[06:00:28] <Colourless> i don't get any crashes
[06:00:53] <Colourless> sure it isn't the crash marzo fixed a few hours ago?
[06:10:22] <Malignant_Manor> This is current svn. There seems to be a loop that is causing it in bggame.cc
[06:10:25] <Malignant_Manor> while (time<1040)
[06:17:12] <Malignant_Manor> Here's a quick path to get to the loop. http://pastebin.com/RRFZFk1e
[06:19:32] <Malignant_Manor> I guess I didn't have mixer up to date. The trunk crashing was up to date.
[06:20:17] <Malignant_Manor> No mixer is crashing still too.
[06:20:42] <Malignant_Manor> Unless it it something I need to compile from scratch.
[06:22:04] <Malignant_Manor> It is with midi though. Ogg didn't crash.
[06:23:17] <Malignant_Manor> I'm cleaning and compiling again. I'll be able to tell if it still happens in about 15 minutes.
[06:38:13] <Malignant_Manor> Confirmed it again
[06:41:44] <-- matt_o has left IRC (Remote host closed the connection)
[07:45:16] <Colourless> what are your exact audio settings. its not causing any problems for me
[07:49:26] <Malignant_Manor> Program recieved signal SIGSEGV, Segmentation fault.
[07:49:27] <Malignant_Manor> 0x004bcda4 in LowLevelMidiDriver::threadMain (this=0x1)
[07:49:29] <Malignant_Manor> at audio/midi_drivers/LowLevelMidiDriver.cpp:503
[07:49:30] <Malignant_Manor> 503 int code = open();
[07:53:35] <Malignant_Manor> audio settings = http://pastebin.com/E6c7vz6C
[07:59:16] <Colourless> same settings as you and i have no issues
[08:02:02] <Malignant_Manor> music and sfx are in data. GDB is the debugger
[08:03:58] <Malignant_Manor> I basically click the mouse in Exult when the Guardian says "Avatar."
[08:04:36] * Colourless tries compiling with mingw
[08:06:13] <Malignant_Manor> Do you want me to send a normal exult exe?
[08:06:42] <Colourless> hmm
[08:06:46] <Colourless> it crashes in mingw
[08:07:30] <Malignant_Manor> My computer compiles slow as hell.
[08:17:10] <Malignant_Manor> Is there any free debugger you recommend for XP?
[08:18:17] <Colourless> heh. i use visual studio
[08:25:04] <Colourless> si intro crahses too
[08:25:17] <Malignant_Manor> Yeah, I mentioned that earlier.
[08:25:25] <Malignant_Manor> Is it the same message?
[08:27:27] <Malignant_Manor> Program received signal SIGILL, Illegal instruction 0x7ffd8001 in ?? ()
[08:38:48] <Colourless> ok, it does it as soon as music starts to play
[08:39:19] <Colourless> don't need to wait for the speech to play
[08:41:13] <Malignant_Manor> makes sense because it is midi that is causing it
[08:42:35] <Colourless> have a feeling its a multithreaded race condition
[09:16:00] <Malignant_Manor> I seem to get several different errors.
[09:16:02] <Malignant_Manor> Program received signal SIGSEGV, Segmentation fault.
[09:16:03] <Malignant_Manor> 0x07c82fd3 in ?? ()
[09:16:05] <Malignant_Manor> Two more illegal instructions (at different times): 0x7ffd7001, 0x7ffd9001
[09:16:21] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158])
[09:44:42] <Colourless> i *really* *really* have no idea why things are falling apart
[10:07:20] <Colourless> all i know is this, its crashing when throwing the exceptions
[10:42:16] <Colourless> i am at a complete loss. i can't figure this out
[10:44:58] <Colourless> i'm going to blame the compiler or something
[11:04:55] <wjp> hm
[11:08:07] <wjp> start the BG intro and click while the guardian is saying 'Avatar'?
[11:08:27] <Colourless> not quite
[11:08:35] <Colourless> nothing to do with the guardian speaking
[11:08:44] <Colourless> it is crashing because its playing midi music... or so it seems
[11:08:58] <Colourless> if oggs are disabled, then when aborting from the intros
[11:09:06] <Colourless> there is a really really high chance of things crashing
[11:09:55] <wjp> I do get a ton of valgrind errors in some functions called from MyMidiPlayer::start_music
[11:11:01] <Colourless> i cant tell whats causing it to crash at all because its crashing in the 'throw' handler
[11:11:09] <Colourless> my guess the stack is corrupt
[11:11:50] <wjp> in case it's relevant: http://www.usecode.org/misc/exult.valgrind
[11:11:57] <Colourless> i'll look at it later
[11:12:45] <wjp> this is on your branch, by the way
[11:13:07] <wjp> ok
[11:17:40] <wjp> oh, and they seem to have disappeared after updating svn
[11:37:10] --> Dominus has joined #exult
[11:37:10] --- ChanServ gives channel operator status to Dominus
[11:38:06] <wjp> hi
[11:38:48] <Dominus> hey ho
[11:45:04] <wjp> ah, this is not good
[11:45:27] <wjp> MyMidiPlayer::start_music does weird things with paths
[11:48:29] <wjp> specifically it assumes that the passed path always starts with <STATIC>
[11:53:47] <wjp> not likely to cause crashes though
[12:05:33] <wjp> although it does look fishy. Won't the temporaries created in mid_data = new ExultDataSource(File_spec(flex), File_spec(pflex), num); be deleted directly afterwards causing the filenames to be deleted while pointers to them are still stored in the ExultDataSource?
[12:11:49] <Dominus> hmm, and something fishy is going on with my static built from my osx 10.5 wmware
[12:12:29] <Dominus> need to find out why it suddenly wants to load from appbundle/content/macos
[12:12:39] <Dominus> load the data folder from there...
[12:20:11] <wjp> instead of?
[12:21:10] <Dominus> it should read it from appbundle/content/resources/data
[12:21:30] <Dominus> and I think it does it on the wm but not on another system anymore
[12:40:36] <Colourless> while pointers to them are still stored in the ExultDataSource? << maybe. i'll look at it
[12:42:19] <Colourless> it doesn't look like it'd matter in this case, but i'll see what the debugger says
[12:43:55] <Colourless> heh, the code is broken none the less
[12:44:08] <Colourless> sizeof("<STATIC>/") is quite wrong :-)
[12:45:54] <wjp> somehow it doesn't work quite as expected on <DATA>/exult.flx :-)
[12:50:32] <Colourless> fixing that up now
[13:07:12] <Dominus> ok, mystery partly solved. seems the bundle will also read the /data dir from outside of the bundle and thus didn'T crash and burn when I started Exult from my source folder :)
[13:07:14] <Colourless> doesn't look like there is anything wrong with the File_spec related code.
[13:07:57] <Colourless> going through the code with a debugger indicated that nothing is kept
[13:08:06] <Dominus> so the bundle is really not reading data from /contents/resources/data but wants to load it from /contents/macos/data
[13:08:47] * Colourless is not reference bundle stuff
[13:09:06] * Colourless is just checking that the line
[13:09:14] <Colourless> new ExultDataSource(File_spec(flex), File_spec(pflex), num); doesnt' contain any problems
[13:09:51] <Dominus> sorry I was just adding to my problem parallel to your seperate problem :)
[13:10:26] <wjp> hm, but the path copied by the File_spec constructor is stored in ExultDataSource's U7multiobject, isn't it?
[13:10:48] <Colourless> U7multiobject is a temporary
[13:10:58] <Colourless> U7multiobject obj(fname0, fname1, index);
[13:11:06] <Colourless> line 449 databuf.h
[13:11:09] <wjp> ah, right
[13:11:15] <Colourless> it duplicates the string anyway in this case
[13:12:53] <-- Kirben has left IRC ()
[13:13:06] <Colourless> hm
[14:01:15] * Dominus curses spotlight and wonders why it can't find stuff in code files which I know is in there...
[14:42:12] <Dominus> hmm, exult will not follow the bundle stuff in utils.cc at first when looking for /data/exult.flx but later when looking for additional data like the sfx it looks at the bundle path given in utils.cc
[14:49:34] * Colourless decides to compile exult using gcc4.4 version of mingw to see if it still has 'issues'
[15:12:27] <Colourless> exult built with mingw using gcc4.4 does not crash it seems
[15:14:20] <Colourless> considering that i can not find a problem with the code (well i have noticed a potential race condition that I ruled out as being the cause), the faulting code has not changed in an aeon, the code previous had no issues and changing the compiler hides the problem
[15:14:29] <Colourless> i'm blaming it as being a compiler/library version issue
[15:18:27] <Dominus> not the first one we had :)
[15:28:09] <Colourless> i am going to bed now
[15:28:29] <Colourless> night all
[15:28:34] <-- Colourless has left IRC (Quit: casts improved invisibility)
[17:35:17] --> Marzo has joined #exult
[17:51:02] <Marzo> So it seems if I had been here earlier, I could have saved Colourless and wjp quite the wild goose chase on the File_spec code :-)
[17:59:33] <Dominus> hey marzo
[17:59:40] <Marzo> Hi
[18:00:20] <Dominus> sorry for overlooking the data folder issue when testing bundle on OS X
[18:00:58] <Marzo> Which one?
[18:02:06] <Dominus> https://sourceforge.net/tracker/?func=detail&aid=2970265&group_id=2335&atid=102335
[18:02:55] <Dominus> it seems that it is NOT looking in the <bundle> for the exult data
[18:11:21] <Marzo> Exult is actually looking for the data in the bundle
[18:12:03] <Marzo> But I also added checks to search for the data dir in case a file isn't in the bundle
[18:12:38] <Dominus> but it isn't finding it in bundle/content/resources/
[18:12:40] <Marzo> But I forgot to add a check I intended to: to go on if the bundle has the file
[18:14:24] <Marzo> I maintain what I said :-)
[18:14:54] <Marzo> That line is not trying to open BUNDLE_EXULT_FLX, it is looking for EXULT_FLX
[18:15:22] <Dominus> so it finds it in the bundle but doesn't know to stop searching for it and then goes on searching for it?
[18:15:43] <Dominus> and thus fails to start
[18:15:49] <Marzo> Part of that behavior is intentional
[18:16:12] <Marzo> For example, so you can have the music oggs outside of the bundle but Exult still be able to find it
[18:16:32] <Dominus> I see
[18:16:33] <Marzo> But there should be an exit clause before the end of the function
[18:18:45] <Marzo> I will also remove that 'error' message as it is confusing to users :-)
[18:19:30] <Dominus> :)
[18:20:05] <Dominus> be back in a few… dinner time :)
[18:40:37] <Marzo> Dominus: when you come back from dinner, can you check if this patch fixes the static compilation on the Mac: http://pastebin.com/19UDKMbf
[19:21:12] <Dominus> hmh… exult seg faulted right now
[19:21:49] <Dominus> seems because of the mt32emu
[19:22:12] <Dominus> grr
[19:22:30] <Dominus> no, without it crashed on journey onward
[19:22:52] <Dominus> I'll make a debug built
[19:30:19] <Dominus> seems that was a fluke, on a clean built (with debug) it works
[19:30:35] <Dominus> Marzo: the audio gump has a new problem
[19:31:15] <Dominus> when you start Exulkt with audio disabled you can't enable it anymore because the ok and cancel button do not show after clicking the enabled of Audio
[19:33:28] <Marzo> I will fix it
[19:33:43] <Marzo> Can you test the patch I gave above?
[19:33:51] <Marzo> For static compilation on MacOSX
[19:34:01] <Dominus> yup, I'm on it right now
[19:37:44] <Dominus> doesn't work
[19:37:45] <Dominus> gcc -o conftest -I/opt/local/include -Wall -I/opt/local/include -L/opt/local/lib -static -Wl,-Bdynamic -lcrt0 -Wl,-Bstatic conftest.c -logg >&5
[19:37:45] <Dominus> ld: library not found for -lcrt0.o
[19:37:45] <Dominus> collect2: ld returned 1 exit status
[19:38:22] <Dominus> as soon as you pass the -static OS X compiler wants to use -lcrt0.o which doesn't exist
[19:38:33] <Dominus> it does that to disable static building
[19:42:04] <Marzo> I will try another approach then
[19:42:11] <Marzo> (but first the audio)
[20:15:08] <Marzo> Dominus: please test this patch now: http://pastebin.com/g9tqcdVa
[20:15:47] <Dominus> on top of your previous patch or the svn version?
[20:16:52] <Dominus> svn :)
[20:16:55] <Marzo> The svn
[20:17:17] <Marzo> (this is, of course, for Colourless' branch)
[20:17:21] <Dominus> yup
[20:19:04] <Marzo> The audio gump fix is away to main trunk, will merge into branch soon
[20:22:22] <Marzo> And it is there
[20:22:55] <Dominus> configure ran through this time
[20:24:07] <Dominus> let's see how make fares and what the binary looks like...
[20:26:28] * Marzo crosses fingers
[20:26:59] <Dominus> he he, right now both my VM and my machine's compilation was "stuck" at the hq3x scaler at the same time :)
[20:27:26] * Dominus is punishing his machine right now with those same time compilations AND the added overhaed of the virtualizing
[20:28:15] <Marzo> The HQ3x and HQ2x scalers really push the limits for compilation
[20:28:59] <Marzo> The HQ3x build takes about 390MB of RAM during compilation on my Windows box
[20:29:11] <Dominus> wow
[20:29:20] <Marzo> Lots and lots of template-generated code does that :-)
[20:29:39] <Marzo> It was even worse, of course, before I split up the scalers into their own separate files
[20:31:18] <Dominus> final linkin failed
[20:32:02] <Dominus> http://pastebin.com/7pVmKy9z
[20:33:11] --> Rottingbeef has joined #exult
[20:35:58] <Marzo> Try editing the patch to use -static and -dynamic instead of -Bstatic -Bdynamic
[20:37:15] <Marzo> (you probably won't have to do a full recompile, but will have to run ./configure again)
[20:39:42] <Dominus> fails http://pastebin.com/4LhViUpE
[20:39:57] <Dominus> but it might be that I DO need to make a full recompile
[20:41:15] <Marzo> Aye, try that
[20:41:22] <Dominus> trying
[20:42:08] <Marzo> I will be going out shortly, and won't be back for some 7-8 hours
[20:42:21] <Marzo> If you are still here at that time, we can continue then
[20:42:44] <Dominus> won't be, I'll have to catch some sleep before getting on the plane :)
[20:42:49] <Marzo> k
[20:42:56] <Dominus> we will have to continue in a month then :)
[20:43:07] <Marzo> Anyway, post the results of this attempt so I know if it worked or not
[20:43:15] <Dominus> I will
[20:44:32] <Dominus> damn it, the static compile from the trunk is seg faulting
[20:44:40] --> Malignant_Manor has joined #exult
[20:45:16] <Marzo> Weird
[20:45:33] <Marzo> Hm
[20:45:53] <Malignant_Manor> Marzo, will you please recommend a good, free Windows debugger?
[20:46:05] <Marzo> Dominus: Are you running it from a terminal in a location in which there is (say) a build from the branch?
[20:46:11] <Marzo> I use GDB
[20:46:43] <Marzo> But you won't be needing it to track down that midi crash that eluded even Colourless
[20:46:56] <Dominus> no, I ran it from the dmg image (which is write protected) and from a non exult folder
[20:47:13] <Malignant_Manor> That's what I tried. It worked a few times to get the functions but not most of the time.
[20:47:37] <Marzo> I already know what is causing it, and the key to it was the fact that Exult worked correctly when Colourless updated GCC
[20:47:51] <Malignant_Manor> Is that a problem with me not loading it correctly?
[20:48:26] <Marzo> To run it correctly, you have to run the exe with the symbols
[20:48:27] <Dominus> Marzo, it crashes when set to Mt32emu and it can't find the roms
[20:48:28] <Malignant_Manor> I'd like to run my tests of Exult in a debugger so that I can actually find problems even if I can't reproduce them.
[20:48:44] <Malignant_Manor> That's file exult.exe?
[20:48:47] <Marzo> You have to compile it with debug symbols enabled, preferably with -O0
[20:49:05] <Marzo> Yes, but not the one that is stripped by the Makefile.mingw at the end
[20:49:23] <Marzo> The one in the compilation dir (which is likely HUGE) is the one you want to run
[20:49:59] <Malignant_Manor> Mine is 112 MB.
[20:50:03] <Marzo> You can tell GDB to load the symbols from this file, or you can run it directly
[20:50:08] <Marzo> That is the one
[20:50:18] <Malignant_Manor> That's the one I run.
[20:51:00] <Marzo> Hm; I never had problems getting GDB to work correctly, even in msys
[20:51:17] <Marzo> (although it doesn't work nearly as well as it does in Linux...)
[20:52:12] <Marzo> Dominus: Exult tries to find the ROMs in the bundle, then in the data dir, then in ~/Library/Application Support/Exult/data
[20:52:18] <Dominus> Marzo: the compilation of the static branch failed with the same stuff
[20:52:19] <Malignant_Manor> Yeah, I've never really ran a debugger in Windows as all the free ones seem to be made for *nix.
[20:52:42] <Dominus> Marzo: It seems that wehn it can't find them anywhere it is now crashing for me
[20:53:05] <Marzo> I will look into it later, then
[20:53:21] <Malignant_Manor> Program received signal SIGSEGV, Segmentation fault.
[20:53:23] <Malignant_Manor> 0x07c82fd3 in ?? ()
[20:53:24] <Malignant_Manor> Is that is from not reading the symbols or normal?
[20:54:08] <Marzo> That is one function for which GDB doesn't have debugging information
[20:54:29] <Marzo> Probably a Windows system library, or a C runtime library
[20:54:46] <Dominus> marzo, it will crash when the only data folder it can find is the bundle data folder
[20:54:49] <Marzo> You can, if you want, download debug symbols from system DLLs from Microsoft
[20:55:08] <Dominus> as soon as I had a data folder at the bundle's location it would go on
[20:55:28] <Dominus> teh crash occured on "journey onward" not on starting exult, btw
[20:56:11] <Marzo> Dominus: So when there is no data at the bundle location it fails?
[20:56:42] <Dominus> no, when there is no other data folder except the one in the bundle
[20:57:03] <Dominus> and yes, if there is no rom in the bundle data it fails
[20:57:12] <Dominus> if you meant that :)
[20:58:27] <Marzo> Will investigate
[20:58:36] <Dominus> I'll make a new and final snapshot without the Mt32emu, so there is at least one for the next month :)
[20:58:36] <Marzo> But I am going out now; so farewell
[20:58:38] <Dominus> thanks
[20:58:40] <Dominus> by
[20:58:42] <Dominus> e
[20:58:46] <Marzo> Have a good night and a safe trip
[20:58:50] <Dominus> thanks
[20:58:58] <Marzo> See you in a month
[20:59:02] <Dominus> :)
[20:59:58] <Malignant_Manor> So it is a compiler issue?
[21:03:45] <-- Marzo has left IRC (Ping timeout: 260 seconds)
[21:30:35] <Dominus> bah, not enabling mt32emu on cnfigure made that snapshot segfault as well, even when it was sure that the mt32emu was not the driver
[21:35:04] * Dominus is highly annoyed
[21:45:45] <Dominus> can't fix it, it's only segfaulting now
[21:46:05] <Dominus> I'm going to pull the snapshot and there will be none until I return...
[21:46:15] <Dominus> I have no idea what's going on
[21:53:17] <-- Dominus has left IRC (Quit: Leaving.)
[21:55:27] --> Dominus has joined #exult
[21:55:28] --- ChanServ gives channel operator status to Dominus
[21:59:44] --> Cahaan has joined #exult
[22:04:33] <-- Malignant_Manor has left IRC (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158])
[22:09:36] <Dominus> found my segfault problem
[22:10:07] <Cahaan> congrats
[22:10:43] <Dominus> Marzo, when you are reading this, your merging of Colourless branch fix for always assuming <static> broke OS X
[22:14:13] <Dominus> rev 6269
[22:30:59] --> Kirben has joined #exult
[22:30:59] --- ChanServ gives channel operator status to Kirben
[22:31:38] <-- Dominus has left IRC (Quit: Leaving.)
[22:31:58] --> Colourless has joined #exult
[22:31:58] --- ChanServ gives channel operator status to Colourless
[22:35:59] <-- julien- has left #exult
[22:56:48] <-- Cahaan has left IRC ()