21 May '13 - 13:26 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1]
  Reply  |  Print  
Author Topic: Bass Crash in 2.4.0.0 and 2.4.0.1  (Read 1327 times)
CliffCawley
Posts: 20


« on: 31 May '08 - 02:47 »
Reply with quoteQuote

I've had this crash about 4 times over the last month. Not very much I know. Some of my users have also had this once or twice themselves.

It seems VERY random, but it definitely occurs. I recently updated to 2.4.0.1 and thought that it may have been fixed, however I just got it 2 minutes ago.

Here are the crash offsets:

AppName: xion.exe    AppVer: 1.0.0.99    ModName: bass.dll
ModVer: 2.4.0.0    Offset: 0000109c

AppName: xion.exe    AppVer: 1.0.0.101    ModName: bass.dll
ModVer: 2.4.0.1    Offset: 0000109c

One from previous version, one from new version.

Unfortunately i can't get it properly reproducible. I *think* it happens when I'm either ending or starting a new song. It usually surprises me so I can't remember what it was doing at the time.

Not sure if it will help you, let me know if there's anything else you need.

Cliff Smiley
Logged
Ian @ un4seen
Administrator
Posts: 15253


« Reply #1 on: 31 May '08 - 14:04 »
Reply with quoteQuote

I've encountered this crash too. In my tests, it could happen when seeking in a playing stream and at the same time (ie. in another thread) freeing the stream. Does that sound like what's happened there? Smiley

Here's an update that should sort it...

   www.un4seen.com/stuff/bass.dll

Please let me know if you still get the crash.
Logged
CliffCawley
Posts: 20


« Reply #2 on: 2 Jun '08 - 04:38 »
Reply with quoteQuote

I've encountered this crash too. In my tests, it could happen when seeking in a playing stream and at the same time (ie. in another thread) freeing the stream. Does that sound like what's happened there? Smiley

Here's an update that should sort it...

   www.un4seen.com/stuff/bass.dll

Please let me know if you still get the crash.

Hmm its possible. I'm creating a new stream in a callback, seeking to the start and unloading the previous. That may well be doing something similar to what you've suggested.

I'll give it a try and let you know how I go, thanks

Cliff Smiley
Logged
CliffCawley
Posts: 20


« Reply #3 on: 2 Jun '08 - 07:04 »
Reply with quoteQuote

Nup, managed to crash it again.

AppName: xion.exe    AppVer: 1.0.0.101    ModName: bass.dll
ModVer: 2.4.0.3    Offset: 000010dd

Different address this time though

Cliff Smiley
Logged
Ian @ un4seen
Administrator
Posts: 15253


« Reply #4 on: 2 Jun '08 - 17:30 »
Reply with quoteQuote

Hmm its possible. I'm creating a new stream in a callback, seeking to the start and unloading the previous. That may well be doing something similar to what you've suggested.

Are you seeking to the start of the old stream or the new one? If the former, then that doesn't sound like it would trigger the problem that I found, as the seeking and freeing need to be on the same stream. If the latter, why? Smiley

Btw, what sort of callback is it? I guess a SYNCPROC? If so, what type of sync is it, eg. is it "mixtime"?

Nup, managed to crash it again.

AppName: xion.exe    AppVer: 1.0.0.101    ModName: bass.dll
ModVer: 2.4.0.3    Offset: 000010dd

Different address this time though

That crash is in the same function as before, but the address is different due to some other code changes. I think I will probably have to send you a debug version to get some clues on what's causing it.
Logged
CliffCawley
Posts: 20


« Reply #5 on: 2 Jun '08 - 22:28 »
Reply with quoteQuote

Ok, here's what I do:

When opening a file, I create two sync callbacks, one when about 5 seconds out from playing a song and one when 100ms out from the end of a song. The 5 second one starts pre-caching the next song.

Pre-caching and Opening go through the same code in the end. The code for opening is done in a separate thread which sets up the 2 syncs for the new stream and immediately calls Pause on the channel so that it isn't started. I'll have to review the code again, but from the looks of it, I'm calling Play, with restart set (in case it was a re-use of the same channel as it goes through the same code), then pausing it again. After that I'm calling BASS_ChannelSetPosition() which sets it to a previously saved time (for when I'm loading halfway through a song), or  0 again, if it wasn't set.
At the point of playing this pre-cached track, I free the other stream just after unpausing the pre-cached track.

I'm probably over calling on some of the functions and need to refactor the code soon as its a couple of years old and was originally for a different API, however I didn't think that what I was doing would cause a crash?

Sure, I'll give the debug build a whirl. If it crashes again with the debug build, is there anything special I need to do? I.e. do I need to click debug on the crash window, or would the callstack be available from the crash window?

Cliff Smiley
« Last Edit: 2 Jun '08 - 22:42 by CliffCawley » Logged
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.18 | SMF © 2013, Simple Machines