OS: Windows 7
With a r43283 build from GraphicAll.org and with my r43553 build from SVN using MinGW+SCons, I am getting fairly regular crashes when I leave a .blend (that is, when I quit, open another .blend, or Ctrl+n).
I caught the most recent one in gdb, and did a bt:
#0 0x76149b60 in msvcrt!memcpy () from C:\Windows\system32\msvcrt.dll
#1 0x73a20db5 in midMessage () from C:\Windows\system32\wdmaud.drv
#2 0x73a21121 in midMessage () from C:\Windows\system32\wdmaud.drv
#3 0x73a1fa11 in midMessage () from C:\Windows\system32\wdmaud.drv
#4 0x73a1f522 in midMessage () from C:\Windows\system32\wdmaud.drv
#5 0x73a1f721 in midMessage () from C:\Windows\system32\wdmaud.drv
#6 0x73a20563 in midMessage () from C:\Windows\system32\wdmaud.drv
#7 0x73a20735 in midMessage () from C:\Windows\system32\wdmaud.drv
#8 0x73a15036 in widMessage () from C:\Windows\system32\wdmaud.drv
#9 0x73a18119 in modMessage () from C:\Windows\system32\wdmaud.drv
#10 0x770aed6c in KERNEL32!AcquireSRWLockExclusive ()
from C:\Windows\system32\kernel32.dll
#11 0x7736377b in ntdll!RtlInsertElementGenericTableAvl ()
from C:\Windows\system32\ntdll.dll
#12 0x7736374e in ntdll!RtlInsertElementGenericTableAvl ()
from C:\Windows\system32\ntdll.dll
#13 0x00000000 in ?? ()
...so something audio-related, but what?
These happen all the time to me, so I can get more information any way you like. Is there some Windows-debugging tool I should download to learn more about those .drv/.dll calls?
Thank you,
-rking
Description
Event Timeline
This seems more like a bug in audio driver and it's not much what can be done from our side before somebody from develoeprs will be able to reproduce this issue. I might suggest switching between different audio backends (SDL/OpenAL), test release builds from blender.org or http://builder.blender.org/download/ (where some libraries were upgraded) and check for audio driver updates for your system.
It's also interesting if crashes happen on specific .blend file or blender might crash on any file you're working with?
Sergey,
First of all, no, it does not matter which .blend I am using. I think I have even had the crash happen for the default scene.
What seems to matter most is the length of time I am running before quitting/switching .blends. Perhaps this is because I use the audio system elsewhere during these stretches of time? I do not have any clues, and that's the second thing I wanted to talk to you all about.
In the stack trace above, I see no part of blender involved. I do not understand the architecture that causes those instructions to get executed. It is not as if blender.exe is calling that code, so it must get there some other way. Is there any way to figure this out? I would love to start instrumenting parts of the code with printf()s, but I obviously can't do that if I don't know what is invoking the crashing code.
Third, Yes, I will try switching audio backends. That sounds like a good suggestion.
And fourth, I see these crashes on all the builds I've tried, other than 2.61-official. Builds from graphicall.org and SVN give me trouble.
Thank you,
-rking
Think code from driver is called from some backend library like SDL or OpenAL and it's asynchronous calls for blender, so don't think setting printf in Blender's code will help you figuring out which call of audio library lead to crash. Even if you find this call, pretty much sure arguments passing to it are correct (because it doesn't crash for plenty of people). So actual error either in OpenAL/SDL (which isn't likely -- otherwise we'll have much more reports about crashing because of audio issues) or bug is in driver itself (you might try disassemble it if you like to debug it).
I think actual things which might help here would be:
- Try to upgrade driver.
- Try to switch between SDL/OpenAL in user preferences.
- Try to set sound system to None in blender and see if crashes will continue.
All this steps better be checked with official builds from blender.org, otherwise we can't guarantee that blender is linked against proper dependency libraries and runtime libraries.
Don't actually think it's a bug in blender. Most probably just crappiness of some drivers. Annoying thing that such kind of issues are difficult to handle it crash doesn't happen for a developers. Wouldn't consider this is bug, but we'll be happy to help you in IRC or we can continue discussion here.