Runtime-Crash in AudioDeviceSelectorComponent (e.g. JuceDemo) @ JUCE v4.1.0, Windows 8.1


#1

May app always crashes at runtime when using the AudioDeviceSelectorComponent an hitting the Test-Button.

Happens to all apps and demos I compuled so far.

My System: JUCE v4.1.0, Windows 8.1

It was working fine in JUCE 3!

E.g. in JuceDemo, I go into "Audio: Settings" Demo, (the Audio device type was "Windows Audio"), I hit the [Test]-Button, the App crashes:

VS2013 Output:

HEAP[JuceDemo.exe]: HEAP: Free Heap block 06DFBF80 modified at 06DFC680 after it was freed

VS2013 Call Stack:

     ntdll.dll!77937366()    Unbekannt
     [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für ntdll.dll]    
     [Externer Code]    
     wdmaud.drv!651e7276()    Unbekannt
     [Externer Code]    
>    JuceDemo.exe!juce::ListenerList<juce::ComboBox::Listener,juce::Array<juce::ComboBox::Listener *,juce::DummyCriticalSection,0> >::callChecked<juce::Component::BailOutChecker,juce::ComboBox *>(const juce::Component::BailOutChecker & bailOutChecker, void (juce::ComboBox *) * callbackFunction, juce::ComboBox * param1) Zeile 182    C++
     JuceDemo.exe!juce::ComboBox::handleAsyncUpdate() Zeile 633    C++
     JuceDemo.exe!juce::AsyncUpdater::AsyncUpdaterMessage::messageCallback() Zeile 34    C++
     JuceDemo.exe!juce::WindowsMessageHelpers::dispatchMessageFromLParam(long lParam) Zeile 49    C++
     JuceDemo.exe!juce::MessageManager::dispatchNextMessageOnSystemQueue(bool returnIfNoPendingMessages) Zeile 118    C++
     JuceDemo.exe!juce::MessageManager::runDispatchLoop() Zeile 130    C++
     JuceDemo.exe!juce::JUCEApplicationBase::main() Zeile 244    C++
     JuceDemo.exe!WinMain(HINSTANCE__ * __formal, HINSTANCE__ * __formal, char * __formal, int __formal) Zeile 90    C++
     [Externer Code]    

 


#2

That's very odd - obviously we test in Windows all the time and have never seen anything like it.

Do you have any wierd-and-wacky audio drivers that could be buggy?


#3

The problem does not appear up to JUCE 4.0.1 but from 4.0.2 on.

If I git-revert to 4.0.1 no problem.

To be even more precisely: on Nov 2nd, you commited some changes on 

juce_audio_devices\audio_io\juce_AudioDeviceManager.cpp

that seem to cause the crash.

I'm just using an onboard realtek codec driver, nothing special.

 


#4

Ok.. thanks for the detailed info!

It does look like there was a bug in that code - it's odd that we didn't spot it sooner, but I'll push a fix in the next couple of hours..


#5

I've been having this same bug (Windows 7/64 bit) but didn't get to reporting it as I haven't worked so much with Juce lately...At least the bug repro sounds very familiar. Hitting the audio test button in the Demo causes a crash.


#6

Yeah, I actually found several bugs in that bit of code when I started looking! I rewrote it this afternoon, so try it again now.


#7

thank you. happy new year, btw.

there still is another problem left. it happens when debugging any application that uses AudioDeviceSelectorComponent (e.g. JuceDemo Audio:Settings), hitting the test button. the following happens at run time when closing the application:

JUCE v4.1.0
*** Leaked objects detected: 1 instance(s) of class AutoRemovingSourcePlayer
JUCE Assertion failure in juce_leakedobjectdetector.h:95

 JUCE v4.1.0, current git master pulled, tested @ Windows 8.1, VS2013, Debug


#8

Happy new year!

But that's definitely the bug I already fixed.. Check that you're really compiling the new code?


#9

..although... I guess it could conceivably still leak if you were to quit the app while the test-tone is still playing. I can fix that edge-case, but if you're seeing the leak after the tone has finished playing, then you almost certainly aren't using the new version.


#10

Thank you. 

I double-checked having pulled the newest head version (including your changes) and rebuilt everything.

But the error is still reproducible performing the following steps:

  1. Run JuceDemo (VS2013 Debug)
  2. go to Audio:Settings --> hit [Test] twice
  3. close JuceDemo

#11

Nope. Honestly, that's the exact bug I fixed a couple of weeks ago.

You must be compiling old code - we often get people saying things like this and then realising they were building from the wrong folder or something.


#12

Come on, please, did you even test it? Maybe the reason lies somewhere else?

Revision: c401515e644801e87925b556c83f7d49c59470dc
Author: jules <jules@juce.com>
Date: 04.01.2016 10:58:08

JUCE v4.1.0
*** Leaked objects detected: 1 instance(s) of class AutoRemovingSourcePlayer
JUCE Assertion failure in juce_leakedobjectdetector.h:95
JuceDemo.exe hat einen Haltepunkt ausgelöst.
*** Leaked objects detected: 1 instance(s) of class AudioSourcePlayer
JUCE Assertion failure in juce_leakedobjectdetector.h:95
JuceDemo.exe hat einen Haltepunkt ausgelöst.
*** Leaked objects detected: 1 instance(s) of class AudioSourceOwningTransportSource
JUCE Assertion failure in juce_leakedobjectdetector.h:95
JuceDemo.exe hat einen Haltepunkt ausgelöst.
*** Leaked objects detected: 1 instance(s) of class AudioTransportSource
JUCE Assertion failure in juce_leakedobjectdetector.h:95
JuceDemo.exe hat einen Haltepunkt ausgelöst.
*** Leaked objects detected: 1 instance(s) of class AudioSampleBufferSource
JUCE Assertion failure in juce_leakedobjectdetector.h:95
JuceDemo.exe hat einen Haltepunkt ausgelöst.
*** Leaked objects detected: 2 instance(s) of class AudioBuffer
JUCE Assertion failure in juce_leakedobjectdetector.h:95
JuceDemo.exe hat einen Haltepunkt ausgelöst.
*** Leaked objects detected: 1 instance(s) of class AsyncUpdater
JUCE Assertion failure in juce_leakedobjectdetector.h:95
JuceDemo.exe hat einen Haltepunkt ausgelöst.
Detected memory leaks!
Dumping objects ->
{46243} normal block at 0x014B8090, 112 bytes long.
 Data: <  K   K         > A0 80 4B 01 C0 80 4B 01 00 00 00 00 CD CD CD CD 
{45277} normal block at 0x064E8328, 1784 bytes long.
 Data: <,               > 2C D5 CE 00 FF FF FF FF FF FF FF FF 00 00 00 00 
{45276} normal block at 0x05DE8898, 16 bytes long.
 Data: < B            K > C0 42 EC 00 01 00 00 00 00 00 00 00 B8 8A 4B 01 
{45275} normal block at 0x014B8AB0, 136 bytes long.
 Data: <        l>      > C8 D4 CE 00 F8 D4 CE 00 6C 3E EC 00 98 88 DE 05 
{45274} normal block at 0x014D8420, 20 bytes long.
 Data: <    ` K      R  > D0 D7 CE 00 60 9F 4B 01 01 CD CD CD 80 52 00 00 
{45273} normal block at 0x0647FBB0, 192040 bytes long.
 Data: <  G         l3 6> B8 FB 47 06 00 00 00 00 00 00 00 00 6C 33 C9 36 
{45272} normal block at 0x014B9F60, 152 bytes long.
 Data: <        (     G > 01 00 00 00 80 BB 00 00 28 EE 02 00 B0 FB 47 06 
Object dump complete.


#13

Another weird symptome I discovered when testing this is that the test tone differs in its length and sounds "cut" (clipped / silence in a hard way). Is that a helpful clue?

Current audio device type: Windows Audio
Current audio device: "Lautsprecher (Realtek High Definition Audio)"
Sample rate: 48000 Hz
Block size: 480 samples
Output Latency: 992 samples
Input Latency: 736 samples
Bit depth: 32
Input channel names: Input channel 1, Input channel 2
Active input channels: 0, 1
Output channel names: Output channel 1, Output channel 2
Active output channels: 0, 1


#14

Of course I tested it! It doesn't leak. And I tested it again today when I added a workaround for the other edge-case I described above. 

The problem you're describing is exactly what I already fixed!

Try putting a syntax error into the code so you can make sure you're building what you think you are?


#15

Yes, again: that was a bug in the old version!


#16

Syntax error hits. Checked out completely new. No improvements :(


#17

I'm really convinced that you're not running the right code!

What happens if you put a breakpoint at line 133:


    void timerCallback() override
    {
        if (! transportSource->isPlaying())
            delete this;
    }

..are you really telling me that it doesn't get hit??


#18

The timer is working, so line 132 hits, but the isplaying condition seems to be always right,

Line 133 (delete this;) is never called.

At quitting the app, the leak assertion hits before the timer callback, so no delete is called here.


#19

OK....!

Well, I can't reproduce that, or see any way it could fail to happen!

Is there anything you can think of that might be unusual about your setup?


#20

I'm sorry.

It works with older juce versions, see above. Same setup (Realtek Audio Onboard, Win8.1x64, i7, using default platform toolset when building VS2013 in Debug mode).

I even played around a bit with the settings (Windows Audio, Windows Audio Exclusive, DirectSound, different sample rates, deactivated audio in different buffer sizes), always the same problem.