 |
I can confirm the first incident. |
 |
Do you have any examples of plugins that crash frequently? I've been using less VSTis myself lately, but the ones I use (mostly Synth1) don't seem to crash. |
|
|
Also, can you please check if OpenMPT 1.18.03.00 (available at ftp://ftp.untergrund.net/users/sagamusix/openmpt/archive/openmpt/ ) also crashes. Instead of crashing, does it show excpetion messages? |
 |
How much RAM memory you have? I have noticed (several times before) when you have a commit charge larger than your available RAM, (for example) I have 504MiB available for system memory but my process memory charged at 130~140% (maybe less or more) in the worst cases. The fact is when you doing other things in other programs (minimized OpenMPT maybe, I do not remember if also happen with only OpenMPT window inactive) operating system will move the unused memory of OpenMPT to page file. After you turn back into OpenMPT, resuming will block and crash OpenMPT with exception messages, this last only if OpenMPT crash. The other is a hang, in a 'not responding' way. As far as I know is not so much related with VSTs, but yes at time of paginating a process of huge memory. Please check if this case also happen for you. |
 |
I've got 4GB RAM. Here's a crash report: Problemereignisname: APPCRASH What I did ? - opened a mod with VSTIs (S3K, S3, S3B from krakli.com; but as I said before, it doesnt matter which VSTI are used), saved it as wav and edited it, but OpenMPT worked fine after that. I left it open, used Firefox for some minutes, than went back to MPT and pressed START -> crash. So yes, it's probably less about saving as wav as it is about leaving MPT and doing something different and then returning. |
|
|
I will test this case. Is no the same OS but happen also for me, and Rakib has a confirmation too. |
|
|
I cannot able to reproduce (in XP), even leaving for a lot of time idle and huge commit charge. Do you have Windows updated? Maybe this will get your system more stable, please let me know if (in the case of) updating makes a change in OpenMPT. |
|
|
It would be really great if you could provide a testcase module with some exact steps to reproduce the problem, preferrably <i>without</i> any other applications (like Firefox) involved. If you switched to Firefox, you most probably stopped audio playback before and resumed it afterwards - please try if simply stopping and restarting audio is enough to reproduce this. |
|
|
Actually I dont think this has to do anything with vst's. This just happened to me with Sagas song cloud number 5. |
|
|
i can confirm this. I opened a little chiptune, stopped it, went to Firefox and did my stuff there for several minutes, than went back to MPT and pressed play -> no reaction followed by a crash: Problemereignisname: APPCRASH It's a different report this time with that Stackhash, but as there were no VSTIs involved, this crash-problem really may not be related to the other stuff I reported in my first post. @Saga Anyway - another thought: I've got 4GB, but as Win7 is only 32Bit, it can't use the whole memory. My system itself is stable, but could MPT be a rare application that has a problem with those unaccessable parts of the memory ? |
|
|
I have windows 7 64 bit with 4GB ram. But I think the issue is that modplug is trying to play something that has been removed from the memory and tries to play it before it has been added again, resulting in a crash. |
|
|
Windows' memory management should be completely transparent to user space applications, so I don't see how that could be an issue for OpenMPT. The first crash is a STATUS_PRIVILEGED_INSTRUCTION exception, and I don't see how OpenMPT could possibly cause this (let alone why it would call a function in OLE32 that it is not allowed to call). This might be an issue with a plugin or sound driver. The latter error is a null pointer exception, though I cannot reproduce that under the circumstances you described. We might have to do some post-mortem debugging there, but I cannot do that for the official 1.19.03 release anymore since I cannot create the appropriate debugging files for that anymore (I have switched over to VS2010). |
|
|
I still have both VS2008 & VS2010. Do you need .pdb files? |
|
|
Anyway here are compilations of r921 with VS2008: Release: http://dl.dropbox.com/u/35217013/mptrack/Release_921.7z Debug: http://dl.dropbox.com/u/35217013/mptrack/Debug_r921.7z |
|
|
How to save the .pdb file. I found how to save as a .dmp file but it was 571MB and I dont think anyone want to go trough that. |
|
|
PDB files just contain information for the debugger itself, they are not created during a dump. What you may want is a minidump. This article might help, though I dunno if it's still valid for newer versions of VS/Windows: http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx |
|
|
Ok, now I got 3840 error. Meaning this time its because of missing dll file. VS2010 says it because of tal noisemaker. |
|
|
I guess you open a dump file. I don't know a lot of how to debug :\ but I recommend use the whole dump (if you load a minidump). If you want to share, you should compress with 7z in LZMA Ultra. This will reduce the size into a more descent 90~150MiB in average. |
|
|
Minidumps aren't as big as DMP files (which are useless anyway) as they don't contain the whole process memory (which also includes shared Windows DLLs that we are not interested in), but they are not created automatically. I'll try to make OpenMPT emit minidumps, but I don't have time for that right now. |
|
|
I've uploaded a version that should create a minidump on crash (it should ask you if you want to create one, and after that it should show the location of the dump file - if it doesn't, the minidump code doesn't work). Please try http://sagagames.de/stuff/mptrack-dbg.7z (as soon as possible, since evaluation of the dump file is fixed to the current code revision) and see if you can trigger any more unhandled exceptions. |
|
|
Doesn't seem to work with that dump file. I triggered two crashes, but what appeared was only the standard windows crash report. |
|
|
I have managed to get the custom "Something bad happened" dialog on both WinXP and Win7. Somehow I think that this only supports my theory that your problem is not located in OpenMPT itself, but rather a broken driver or something similar. Do you have access to a second machine on which you could try OpenMPT and check if the same crashes appear here? |
|
|
http://tdistler.com/2009/04/10/stackhash-and-application-crashes-on-windows gives some more ideas of what's going wrong in the second crash (comment 0000334). You could try adding mptrack.exe to the exception list for Data Execution Prevention (as described in the first comment on the link above), and check if that helps identifying the crashing module. |
|
|
It isn't possible to add your dump-file version in that exception list (win says, this program can only be executed with Data Execution Prevention). So no new information at all. |
|
|
I've updated the debug package to also create a minidump if the audio thread dies (hopefully that'll work), download link is the same as above. |
|
|
I have not tried with the modplug with the minidumper yet, but I tried to disable DEP for modplug 1.20.00.08 and it gave me an error saying its not possible. |
|
|
Well OK, I didn't know that this setting can't be overriden. That shouldn't matter if you get the minidump to work, though. |
|
|
I created a dump and attached it to this thread. |
|
|
The crash does indeed happen in a DirectSound call. Since you are on Win7 anyway, you should prefer using a WaveOut (yellow speaker icon) or, even better, an ASIO driver (red ASIO icon) instead of DirectSound. If there is no ASIO driver for your soundcard, you can try ASIO4All. |
|
|
To get some more clues about the crash, please post your custom sound card configuration (all details from the "Sound Card" tab in OpenMPT's settings). |
|
|
Sound Device: Primary Sound Driver I'll check that ASIO out... /update:
|
|
|
<blockquote>I wasnt able to get any sound out of asio4all yet</blockquote> BTW, you really should lower your audio buffer size from 200ms to something like 20-30ms. You really don't want your pattern view to move that jerky, do you? |
|
|
Not related, but Im using now the modplug with the minidumper. But this crash happened during start of exporting to wav file. The dumpfile enclosed. |
|
|
"ASIO4All requires exclusive access to the audio hardware, so if another application (f.e. an audio player) is running that already plays some audio, ASIO4All will not emit any sound on that device." "BTW, you really should lower your audio buffer size from 200ms to something like 20-30ms. You really don't want your pattern view to move that jerky, do you?" |
|
|
rakib: That is an unrelated issue, since the crash happens in NoiseMasker and not the DSound module. I can reproduce the crash, or most precisely, using the latest test version, the plugin is set to bypass when it crashes, like in older versions of OpenMPT. Exception handling got broken when switching to VS2008, now the correct exception handling settings are used again in VS2010. |
|
|
Ok, try this then. |
|
|
I cannot make any sense out of that, OpenMPT is not even in the call stack - only OLE32 and the Microsoft C runtime are. |
|
|
Well, I remember a crash a few days ago, where ole32.dll was mentioned in the crash report, if that helps... |
|
|
Well, you can try again using http://sagagames.de/stuff/mptrack.exe - this version should produce less crashes with plugins and also automatically create a dump file when it crashes. |
|
|
And where is this file located ? Problemsignatur: But the good news is, that it took a much longer time until it happened. First I tried (with primary sound device of course) a tiny mod and 30 minutes later the new version still didn't crash (for the old version that was a good time to provoke a crash). Then I loaded a mod with VSTIs and 20 minutes later again MPT still worked, even I did some memory wasting stuff with Firefox. I tried another mod with another VSTI and around 20 minutes later pressing play finaly causes this crash. But I can live with that. As long as the rate of those crashes isn't in a region of annoyance anymore, it's fine by me... |
|
|
<blockquote>And where is this file located ?</blockquote> If the number of crashes decreased but you don't get any "Plugin crashed" message boxes, then the change is not related to anything that has been done to the code lately. |
|
|
Haven't seen any "plugin crashed" or other messageboxes, and there's also no dumpfile-dir in the temps. Problemereignisname: AppHangB1 |
|
|
Regarding the random crashes (especially when switching to other applications), can any of you who have this problem confirm that they are using a Realtek High Definition audio chip? |
 |
I would not be surprised about Realtek. My motherboard got power-surged a year or two ago, blowing the resistors or capacitors or whatever that was that my tech guy showed me. But anyway he replaced everything, but i lost my Realtek and he replaced it with VIA HD. I don't seem to have nearly the same audio problems as i had back then, even though i have fewer features. So if it's a driver problem with Realtek, it would seem to make sense... |
|
|
Hardware manager says, I've got an AMD High Definition Audio Chip, but it shouldn't be active, because I'm using a SB Audigy-Soundcard (whose drivers are rubbish too). |
|
|
I did a very small modification to the DSound code after I was able to catch one of those crashes "Live" - Can you please try if this build makes any difference to the crash behaviour? http://sagagames.de/stuff/mptrack.exe |
|
|
To get some more clues what's going wrong, I've added some message boxes now, so if a weird message saying "WTF! ..." pops up, please tell me - I need to know the exact message. |
|
|
Hadn't much time to test it, but with the >leave it open for some time, than press play<-methode I wasn't able to create a crash yet. Could be a good sign. But that new version may have two other tiny bugs:
|
|
|
Regarding 1, that has already been reported and fixed in issue 0000239 |
|
|
We have recently been working on the audio code to make opening / closing devices more reliable and getting rid of race conditions and other similar bugs. First off, if the original problem - OpenMPT crashing randomly with DirectSound output - is still happening to anyone here, please say so in the comments, so that I know who's still having problems with this bug. Then, please download http://sagagames.de/stuff/mptrack-fix.exe and play around with it. With a bit of luck, this fixes the original problem. If the problem then doesn't happen for you anymore, please also state that in the comments. |
|
|
Apart from a very few immediately crashing VSTIs I noticed, this new version seems to run stable. No crashes in DirectSound-mode so far. |
|
|
Well, VST crashes are a completely different issue - if you find any plugins that crash frequently and reproducably, please open a separate issue for that - although I expect it to be a plugin issue and not a general issue with OpenMPT. Good to hear that the code is running well so far. I'll keep this issue open for a bit longer, and if any of these annoying DirectSound crashes reappear when starting playback (as in the old versions), please tell immediately. Basically you want the update interval to be as low as possible. 1 ms is best, and any halfway decent computer should be able to handle such a short update interval, but depending on what you do, 5 - 10 ms might be just enough (e.g. when not doing any live note recording). |
|
|
Please check if this still happens with the latest version of OpenMPT: http://sagagames.de/stuff/mptrack.exe |
|
|
Just a note to tell I have no more freezings with DirectSound, I always use on another machine with Realtek HD Audio and Windows 7 and I have no issues with this. It is better to use WASAPI? |
|
|
WASAPI is much better, especially in exclusive mode. |
|
|
I'll close this for now as there is a big chance that this has actually been fixed. If the bug reoccours, please let me know! |
- Anonymous
