[01:14:27] <Marzo> Dominus: are you still here?
[01:24:41] --- Marzo is now known as Marzo_away
[04:22:08] --- Colourless` is now known as Colourless
[05:05:50] --- Colourless` is now known as Colourless
[13:28:20] --- Marzo is now known as Marzo_away
[15:44:25] <Dominus> Marzo, I'd be here now
[16:00:33] --- Marzo_away is now known as Marzo
[16:00:52] <Marzo> I will be back in about 30 min, if you are here for some debugging then
[16:05:37] <Dominus> ok, np
[16:16:00] --- Marzo is now known as Marzo_away
[16:50:40] --- Marzo_away is now known as Marzo
[16:50:57] <Marzo> Sorry, it took a little longer
[16:51:09] <Marzo> (than I anticipated)
[16:51:18] <Dominus> hey ho, no problem
[16:52:03] <Dominus> to recap, I cleaned the coremidi driver up a bit and made it its own driver in Exult. The current code is http://pastebin.com/m22f83cc6 CoreMidiDriver.h; http://pastebin.com/m758da8c8 CoreMidiDriver.cpp
[16:52:20] <Dominus> db bt of the crash with coremidi driver and mt32 conversion http://pastebin.com/m41497361
[16:52:38] <Dominus> this is gdb exult, run (then it crahes), bt
[16:53:07] <Marzo> Is gdb open?
[16:53:21] <Dominus> nope, I'd have to do it again
[16:53:28] <Dominus> one moment
[16:54:33] <Dominus> same procedure? gdb exult, run
[16:54:41] <Marzo> Aye
[16:54:58] <Dominus> k
[16:55:01] <Dominus> done
[16:55:04] <Dominus> bt
[16:55:42] <Dominus> same bt
[16:55:47] <Marzo> Type 'up'<enter> until you reach XMidiEvent::Free
[16:55:58] <Marzo> (should be 3 times)
[16:56:12] <Dominus> k
[16:56:35] <Dominus> #3 0x00000001000d7e3b in XMidiEvent::Free (ptr=0x100c64ee0) at XMidiEvent.h:131
[16:56:35] <Dominus> 131 ::operator delete(ptr);
[16:56:35] <Dominus> Current language: auto; currently c++
[16:56:44] <Marzo> k
[16:56:52] <Marzo> up another time
[16:57:05] <Dominus> #4 0x00000001000d4466 in XMidiEventList::deleteEventList (mlist=0x100c64ee0) at XMidiEventList.cpp:246
[16:57:05] <Dominus> 246 XMidiEvent::Free (event);
[16:57:34] <Marzo> Type 'p *event'
[16:58:22] <Dominus> http://pastebin.com/d527182b7
[17:04:35] <Marzo> Hrm. Odd.
[17:05:28] <Dominus> any idea?
[17:06:02] <Marzo> Some, but I am still looking around
[17:21:16] <Marzo> Will need some more information
[17:21:58] <Dominus> k
[17:22:09] <Marzo> 'up' until LowLevelMidiDriver::loadTimbreLibrary
[17:22:50] <Dominus> #7 0x00000001000d07cd in LowLevelMidiDriver::loadTimbreLibrary (this=0x10109aa00, ds=0x10095caf0, type=MidiDriver::TIMBRE_LIBRARY_XMIDI_FILE) at LowLevelMidiDriver.cpp:1298
[17:22:50] <Dominus> 1298 delete xmidi;
[17:22:50] <wjp> 'frame 7'
[17:22:58] <wjp> (to jump there directly)
[17:23:06] <Dominus> :)
[17:23:22] <Marzo> Didn't know that
[17:24:34] <Marzo> That crash happens on Exult Menu, right?
[17:25:03] <Dominus> no, it happens right on start up
[17:25:11] <Dominus> I don't even see the exult logo
[17:25:18] <Marzo> k
[17:25:24] <Marzo> (just making sure)
[17:25:54] <Dominus> the Exult window will be outlined and grey but it won't switch to the black exult logo screen
[17:41:39] <Marzo> That is odd; I can't find anything specific to CoreAudioMidiDriver in this problem
[17:41:56] <Marzo> Which means it should also have been happening for other drivers
[17:43:41] <Marzo> brb
[17:43:49] <Dominus> hmm, I think I did encounter another crash once with the mt32 when I updated the docs. I think I did make a bug report
[17:46:06] <Dominus> https://sourceforge.net/tracker/?func=detail&aid=2822446&group_id=2335&atid=102335
[17:46:24] <Dominus> again for coreaudio
[17:48:27] <Dominus> let me build a fluidsynth and timidity enabled exult and I'll see whether another driver also has problems.
[17:49:04] <Marzo> I will have to go out; be back later (about 1 hour or so)
[17:49:13] <Dominus> ok
[17:49:15] <Dominus> see you then
[17:59:19] --- Marzo is now known as Marzo_away
[17:59:28] <Dominus> it's not coreaudio specific, timidity crashes, too, when mt32 is set
[18:00:14] <Dominus> fluidsynth I have to install first, but I guess that will crash, too
[18:17:52] <Dominus> ok, fluidsynth does not crash, with mt32, but the MT32Emu DOES crash similar to coreaudio/mt32
[18:18:12] <Dominus> and mt32emu doesn't even allow setting converse..
[18:18:53] <Dominus> taht could help since I *think* scummvm does also have mt32emu code… have to look if that crashes, too on os x or not.
[18:19:01] <Dominus> later, got to help with dinnner
[18:45:35] <Dominus> how come the exult mt32emu code looks so similar to the scummvm code? (rethoric question) :)
[18:49:26] <Dominus> yep, now that I made a debug build with mt32emu, it crashes exactly the same
[18:50:57] <Dominus> now I'll have dinner and then I'll compare the scummvm code to the exult code for differences...
[19:23:59] <pupnik> good deal
[19:35:03] <Dominus> hmm, probably an excercise in futility, since it doesn't crash in the driver but in the backend and that is something I can't decipher with my knowledge… :)
[19:38:50] --- Marzo_away is now known as Marzo
[19:40:10] <Marzo> I won't be able to help for the next few hours (everything is taking longer than anticipated), but I will probably be back in about 4 to 4 and a half hours
[19:41:22] <Dominus> hmm, I might be in bed then and not availlable until saturday. I'll poke you then or you can poke me :)
[19:53:19] --- Marzo is now known as Marzo_away
[21:13:37] <Dominus> wjp, maybe you have an idea. When I uncomment #543 in XMidiFile.cpp 'events[i]->decerementCounter();' Exult doesn't crash
[21:13:47] <Dominus> when conversion is set to MT32
[21:14:39] <wjp> your backtrace seems to indicate something is going wrong while cleaning up the xmidi structure
[21:14:58] <wjp> removing that line would prevent the entire deletion
[21:15:11] <wjp> so it makes sense that that avoids the crash, but it'll probably leak memory
[21:16:01] <wjp> do you have valgrind?
[21:16:05] <Dominus> ok, that makes sense to me
[21:16:16] <wjp> that's the tool I'd use if I could reproduce it here
[21:16:34] <Dominus> I can see if I caneasily install that via macports
[21:17:51] <Dominus> installing
[21:21:36] <Dominus> nope, valgrind doesn't build on Snow leopard...
[21:22:39] <wjp> pity :/
[21:23:05] <Dominus> https://bugs.kde.org/show_bug.cgi?id=205241
[21:24:21] <Dominus> apart from that, do you think it would be okay to add the coremidi driver to exult?
[21:25:29] <Dominus> should I file a patch for that? since I've managed to correctly copy/paste the stauff, so it is seen as a standalone driver and not a hacked coreaudio
[21:25:32] <Dominus> driver
[21:26:36] <wjp> from what you said about CoreAudio/CoreMidi, adding it sounds like a good idea, but Fingolfin or another mac dev should probably take a look at it
[21:28:10] <Dominus> that makes sense. how do I make a patch from my altered exult structure compared to an unaltered one?
[21:29:47] <wjp> first 'svn add audio/midi_drivers/Coresomething.h audio/midi_drivers/Coresomething.cpp', then 'svn diff > coremidi.patch'
[21:32:53] <Dominus> thanks, will do that now, need to clean other stuff, too first :)
[21:34:40] <wjp> if the things to clean up are in separate files, you can specify a list of files to svn diff ('svn diff audio/midi_drivers/Coresomething.{h,cpp} audio/somethingelse.cpp etc > coremidi.patch')
[21:35:02] <wjp> if they're in the same files as the real changes, you'll have to clean up :-)
[21:35:28] <Dominus> that helps, thanks!
[21:57:37] <Dominus> https://sourceforge.net/tracker/?func=detail&aid=2892212&group_id=2335&atid=302335
[22:00:18] <Dominus> another question wjp, on OS X I have glibtool/glibtoolize, so I've changed my autogen.sh. Is there a permanent way to fix this? Or will I have to just live with that?