Author Topic: access violation bug  (Read 567 times)

pgruebele

  • Posts: 48
access violation bug
« on: 2 Aug '18 - 10:26 »
I have a c# windows desktop app which uses bass for various things (streaming filtering, opus compression, ogg writing etc).  After suspecting bass-caused corruption I enabled gflags to find the problem and it confirmed bass illegal memory access:

Exception thrown at 0x00007FF8273D4CDB (bass.dll) in xxxx.exe: 0xC0000005: Access violation reading location 0x0000027C8C90BFD0.

The call stack is as follows:

   bass.dll!00007ff8273d4cdb()   Unknown
    kernel32.dll!BaseThreadInitThunk()   Unknown
    ntdll.dll!RtlUserThreadStart()   Unknown

I am using the latest x64 versions:

Bass.Net.dll: 2.4.13.2
bass.dll: 2.4.13
bassenc.dll: 2.4.14
bassenc_opus.dll: 2.4
bassmix.dll: 2.4.8
bassopus.dll: 2.4.1
bass_fx.dll: 2.4

This seems to happen randomly after many bass calls.  I am hoping the call stack will narrow the problem down for you.  If you have debug symbols available I can look into this a bit more as well.

The command enable gflags:  gflags /p /enable xxx.exe /full
And to disable gflags: gflags /i xxx.exe ffffffff

If you have test projects, I recommend running them with gflags over longer periods of time in order find heap corruption issues.
My application is heavily multithreaded so perhaps that could be related, but I use specific handles only from the thread they were created in.

Getting symbols for the above libraries could be very useful in narrowing things down further.

Thanks!

pgruebele

  • Posts: 48
Re: access violation bug
« Reply #1 on: 2 Aug '18 - 14:57 »
It seems the issue is related to a combination of

1. having many threads call bass (but I am using bass handles ONLY from the thread that allocated it)
2. one of the threads is making LOTS of calls to BASS_StreamCreatePush, BASS_Mixer_StreamAddChannel, BASS_Mixer_ChannelRemove, BASS_StreamFree.

The reason for #2 is that because we need BASS_STREAMPROC_END to get the full result each time we call BASS_StreamPutData/BASS_ChannelGetData, we need to recreate the handles each time since bass won't allow reuse after of a handle BASS_STREAMPROC_END.  If there is a way to reuse the handles after BASS_STREAMPROC_END this might help alleviate the problem although there looks to be an underlying bug in bass that's causing the crash.

My guess is that bass has some reentrancy issues when it comes to allocating/freeing handles from multiple threads, but I could be wrong...



Ian @ un4seen

  • Administrator
  • Posts: 21211
Re: access violation bug
« Reply #2 on: 2 Aug '18 - 14:59 »
Please first try this latest BASS build:

   www.un4seen.com/stuff/bass.zip

If the the problem still happens with that then please also upload a dump file for the crash (with that latest DLL). You can generate a dump file using the ProcDump tool. For example, run "procdump -e -ma -x . your.exe". Then ZIP and upload the generated dump file to have a look at here:

   ftp.un4seen.com/incoming/

pgruebele

  • Posts: 48
Re: access violation bug
« Reply #3 on: 2 Aug '18 - 15:23 »
OK I am doing some more tests.  I found that I was freeing the same handle twice so perhaps this is what caused corruption?  I will post back after I let things run for a while.

pgruebele

  • Posts: 48
Re: access violation bug
« Reply #4 on: 2 Aug '18 - 17:25 »
Double-freeing did not solve the issue.  Also the newer bass.net link you sent me seems to cause the problem even more frequently and also gives a different stack.

I ftp'd the dump to you.  The first upload failed so look for a file size of 240978446 bytes.  This was captured using the newer bass.dll.

Cheers

Ian @ un4seen

  • Administrator
  • Posts: 21211
Re: access violation bug
« Reply #5 on: 3 Aug '18 - 14:45 »
The dump file was received, thanks. I can see from that where the crash happened but it isn't obvious why it happened. I will investigate it some more and then send you an update to try.