Exception thrown: read access violation. juce::HeapBlock<juce::AudioProcessorListener * __ptr64,0>::operator[]<int>(...) returned 0x3CA20000

Ok… No, I’m not using highres timer.

This kind of error would not appear from threading issues.
Are you never calling processor.addListener() at all?
Somehow something ends up being in the AudioProcessor’s ListenerList dangling. And normally only the wrapper is supposed to be in that list. It would be interesting to find out, how that can happen, since that would be a problem for all plugins then.

Yeah, never calling that :stuck_out_tongue:

Well I’ve got a hunch on something. So my plugin draws an histogram curve, and during that process it needs to fetch stuff from the processor. for example I’ve got an AudioParameterInt called resolution it will need. Well. What I did, Instead of directly fetching the resolution->get(), I created a method in processor that instead returns rez (int variable), that’s being set in the processBlock, so basicly rez = resolution->get(); So, it does not need to use resolution audioparameter directly anymore. Well I only tried this once, but now the crash is different, and there’s no processorlisteners this time. It’s another method in processor which sets a variable in an object that’s part of my EQ’ing based on user action on the EQ graph. It’s being set from the timer’s callback.

This leads me to assumption that for some reason using a timer in GUI thread setting stuff on processor might not be the best idea, but why? Timer’s interval is 20 ms, so it happens quite rapidly and might stack up(?) if computer’s performance degrades. Any better solutions for updating stuff based on time or “fps” ?

well, from that aspect it leaves me clueless, but in the following there are hints.

Is this something you want to automate from the host? Otherwise you can simply save the value in setStateInformation / getStateInformation, you don’t need to expose that to the host.

If you are setting the variable in processBlock and read it from the GUI, the minimum is to wrap it in std::atomic.

All in all it seems to me, like your call stack got corrupted, when the variable was accessed from different threads.

Yes you’re right, I don’t need to automate that. :slight_smile: I’ll check out the std::atomic, it’s probably a safe bet.

I miss coding old games where you updated the frame each main loop and so everything happened smoothly in order. :smiley:

Any ideas how to update something based on “fps” in JUCE? So that when I want to paint the GUI, I wouldn’t end up bloating the call stack with timer callbacks if it’s too fast for the computer to handle? Maybe set a variable in paint-method that allows next timer callback to actually do something (call repaint() or so)? Or is there a better way? A way that does not include any timers?

Actually the Timer is the solution, not the problem:

  • A Timer schedules an event on the MessageThread to occur after a certain time. So you have no problems between timerCallback() and all the GUI methods like repaint(), they are on the same thread.

  • To achieve a certain FPS, just start the timer like timer.startTimerHz (fps); Since it is scheduled, it can vary about a few milliseconds, but startTimerHz (30) works for most analysers or GUI refreshes.

  • The paint method is not directly called but through the OS. Calling repaint() sets the area in repaint (Rectangle<int>) as dirty, but the OS will decide, when to callback paint (Graphics&).

  • The paint() needs to be able to read whatever it needs to know to paint at any time. The paint() callback does not have to come from a repaint() call, it could also be just something dragged over the window, or similar events. But if in doubt between MessageManager and AudioThread, the messageManager (or paint() call) should be the one waiting.

Hope that helps

Ok thanks! :slight_smile:

Hmm now I got an error of corrupted heap; The plugin wrote something after the end of the heap, when I pressed stop on the debugger. x_x Weird that I have not met these errors before on previous plugin projects…

Are you using a lot of old school raw pointers and similar stuff? Best is to start using smart pointers and RAII principles. The modern language and std containers help you to avoid these kind of problems…

Good luck

I think I have zero raw pointers (except the audioparameter-objects, which get’s created during the addparameter-methods) and I’ve avoided them most of the time anyways… I hope std::atomic solves my problems, I’ll get back once I’ve implemented that. Thanks a lot, you’re all been a big help! :slight_smile: