Hitting assert in AudioPluginHost loading VST3 - JUCE 8.0.3

Audio Plugins
1

I am using JUCE 8.0.3 on MacOS 11.7.7 (Big Sur).

I have not tested with AudioPluginHost since I moved to JUCE 8 a month or so ago, I believe.

When I first launch it, by running from the debugger, loading any VST3 hits this assert at line 402 of juce_VST3PluginFormat.cpp:

        if (const auto hostTime = position->getHostTimeNs())
        {
            context.state |= ProcessContext::kSystemTimeValid;
            context.systemTime = (int64_t) *hostTime;
            jassert (context.systemTime >= 0);
        }

As you can see, the value of context.systemTime at that moment is some large negative number.

Once I move past the assert, it doesn’t happen again with further loading of that VST3. But loading a different VST3 hits it again.

Any idea what’s going on here?

juce
juce1920×1348 244 KB

2

That value is provided by the audio device. I don’t think it should be negative, but it’s provided as a uint64 by the audio device, so it might become negative when converted to int64. You could take a look at the very bottom of the call stack at the point of the assertion, and check the value of the local variable nanos in CoreAudioInternal::audioCallback to see whether this is a huge value that would become negative after conversion to a signed type.

The really confusing part is that the assertion is only hit once per VST3. If the problem were due to a huge timestamp value, I’d expect the assertion to fire on each consecutive audio callback, not just the first. This makes me think that we may be reading an uninitialised variable or something similar.

Please could you try rebuilding the AudioPluginHost with Address Sanitizer and Undefined Behaviour Sanitizer enabled, and check whether you get the same behaviour?

It might also be interesting to try rebuilding the AudioPluginHost from JUCE 7, and checking whether you see the same issue. If you don’t, then that would imply the assertion was introduced by a specific change in JUCE. Identifying the change that introduced the new behaviour would help to diagnose the problem.

3

The next time I happened, I checked ‘nanos’ (I think this is where you meant?). As you can see, the value is 18431667108562547821. Back up the call chain, that seems to become a negative value:

nanos
nanos1840×1506 438 KB

nanos2
nanos21840×1506 468 KB

I may have mispoke - it does not seem consistent at all. Sometimes it happens, sometimes it doesn’t, sometimes it re-happens with the same VST. But it doesn’t keep happening with each call to process block or anything. You “continue” past the assert and then it works properly it seems.

I have not yet had a chance to try Address Sanitizer as that is not really something I have experience with, but I will do so if this observation doesn’t help.

Would this have anything to do with how long the computer has been running? I haven’t rebooted this laptop in awhile…

EDIT: rebooted the laptop. Still hits… sometimes…