next »

[Ian @ un4seen]

The dump was received, thanks. In this case, a "strdup" call has crashed in a thread that opens a connection with a server. A pointer to a parameter structure is passed to the thread, and the thread makes a copy of it before starting the connection process. In this case, I guess the memory was invalidated/reused after the connection timeout was exceeded before the thread even got a chance to run. Was the system extremely busy (eg. 100% CPU usage) and/or was the BASS_CONFIG_NET_TIMEOUT setting lowered? Anyway, to remove the possibility, here's an update that will make a copy of the structure before launching the thread...

   www.un4seen.com/stuff/bass.dll

Please try that and see if you can still reproduce the crash.

[Jens Lühmann]

Hi Ian,
it looks much better
You're right, i'm testing under 100% cpu performance ( stress test! ) and now it works much longer than before, but i had another crash:

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for kernel32.dll -
kernel32!InterlockedDecrement+0x9:

I just uploaded the last dump file to your server ( AirplayControl.exe.3788.zip )

thanks and best wishes
Jens

[Ian @ un4seen]

In this case it has crashed in the connection opening thread again, inside the actual connection opening call. The crash isn't in BASS (the call stack shows 14 frames between BASS and the crash), which makes it harder to know what has gone wrong. As in the previous case, it is probably related to the connection timeout being exceeded. I think I will have to send you a debug version to get more info on this.

[Jens Lühmann]

Hi Ian,
under normal circumstances the 100% performance does not take place. My application automatically reduces the streams in order to protect the overload. But I've found that it then crashes after 1 week or later. That's why i overload the cpu a little bit to see what's going on. Hope that makes sense for you.
It may also be that the program would run stable now with the update under normal performance. Therefore, I should test it first on longer period, right? Would be great if you send me the debug version.

Thanks and best regards
Jens

[fmcoder]

Ohh! That looks like a problem I faced couple of years ago. Random crashes after a week or two. Extremely annoying to debug...

The solution I finally went with it to create a "watchdog" application which monitors my app and restarts it in case of crash

Yes, It's not a beautiful solution, but it works. Ian, how can I help you with catching this bug? I have a Win 2008 R2 server on which I can run the tests. How do I get the dumps, as DRWTSN32 utility does not present there? If there are some debug versions of bass.dll and bassmix.dll please post links to them. In about 50% cases I get an AV in the BASS_Mixer_ChannelRemove, that's why I'm asking about debug version of bassmix.

Thanks for looking into this problem.

[Ian @ un4seen]

It is still being tested, but it looks like Jens' issue has been resolved. Here's the latest BASS build including that fix...

   www.un4seen.com/stuff/bass.dll

The issue Jens (and Lowdown before him) had was related to internet streams. From your description, it sounds like yours is probably something different. If the crash still happens with the update, to get some info on it, you can tell Windows to generate dump files (in your user "AppData\Local\CrashDumps" folder) by adding this "localdumps-full" registry entry...

   www.un4seen.com/stuff/localdumps.zip

Please reproduce the crash after that and upload the generated dump file (it could be quite large so ZIP it first) to have a look at here...

   ftp.un4seen.com/incoming/

Make sure you're using the latest BASS.DLL (above) and BASSMIX.DLL when doing that. You can use the "localdumps-off" registry entry to disable the dump file generation.

[fmcoder]

Yes, "mine" crash happened without using internet streams. Thanks for the info, I started the testing.

[fmcoder]

Ian, about that "stuff" bass version - can it be used in production?

[Ian @ un4seen]

Yes, it should be fine to use in releases. The only thing I can think of that may have an adverse effect is a change in the SPEAKER flag processing on Vista/7 systems; it doesn't seem to work well with Realtek's driver at the moment, but it is useful otherwise, so it will probably be optional in the release version. Here's a thread on that...

   www.un4seen.com/forum/?topic=13465

[fmcoder]

This only affects DirectSound, right? And if I'm using WASAPI output, where speaker flag is added via BASS_Mixer_StreamAddChannel, everything will work as expected?

[Ian @ un4seen]

Yes, that is correct. The change only applies when using SPEAKER flags with BASS/DirectSound playback (eg. in BASS_StreamCreateFile calls), and won't affect mixer processing.