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

General JUCE discussion
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.