Access violation at address 00007FFFC3CE630 in module

Audio Plugins
1

I currently have this error. I think its dude to implementing xml code being saved on the server. However, it only happens with my plugin is reopened???

Any clue on how to get started to find this? The error is in FL

2

Use your debugger (Xcode? Visual Studio?), and it will stop at the location of the exception. Then you can examine the Call Stack to see where it started going wrong.

3

arent

Access Violation at address xyz

exceptions for when protected memory was requested by something that does not have permission to access it?

no expert, but if it were me, considering it only happens upon re-opening the plugin, i would first assume it is a GUI problem and then considering the memory exception, would assume it had something to do with me deleting a pointer or derefferencing something when the plugin is closed.

my thought process is like

init runs fine → closing plugin works fine → re-opening crashes → maybe i messed up by deleting something that is called is a gui component, which is rerun when the plugin is opened again.

can you ttach a debugger to it and see where it fails?

4

I think it’s something along those lines with a reference being passed. It’s weird because the file location had no problem. Is it possible to be passing to many reference’s from a parent to its children?

Idk but yeah I will have to do a debug session. However, the error is only on windows and I started doing Mac first development because I had to many errors on Mac. Now its the other way around.

5

Yeah that’s my next step!

6

Hey guys just started a debug session and wow!

I think it was grabbing a system font that was on Mac but doesn’t seem to be on windows.

This is a theory I will get back once. I have ran more tests!

1 Like
7

would this not have instantly been a problem on the first instance though? if upon opening for the first time it called something that did not exist?

1 Like
8

I agree with @SourGummi. Perhaps you only hit an assertion (a “jassert” line) when the font wasn’t found? If so, you can hit Continue/Go and continue debugging from there, until the access violation occurs.

9

I have a bunch of jasserts on font. But I don’t think that is it. Ill have to get the debugger working on windows and see. Its clear the windows error will not be fixed on the Mac side.

Thanks for helping! Let me run a few more tests!

10

Yes, I have assert errors on the font however, the font is within my binary resources. So to the windows debugger!

11

“This assertion is triggered if you try to delete a LookAndFeel object while something
is still using it!”

I’m going to move around some pointers as well as clean up some look and feel object code. I think I might be multiple deleting pointers one inside the child and one inside the parent!

1 Like
12

The LookAndFeel is reference counted (but not to control the life time, only to warn you of that situation).

If your class, e.g. PluginEditor owns the LookAndFeel and at the same time has this lookAndFeel set, it is possible that the lookAndFeel is accessed during destruction.

That’s why you should add in your destructor the call

PluginEditor::~PluginEditor()
{
    setLookAndFeel (nullptr);
    // ...
}

That will silence the jassert and avoid a crash during shutdown the plugin.

13

I found that I was accessing a scoped pointer from outside it’s scope.

Thanks Daniel.
I’ve found this code to be pretty handy for cleaning those up in deconstructor.

auto numChildren = getNumChildComponents();
for( int i = 0; i < numChildren; ++i )
{
getChildComponent(i)->setLookAndFeel(nullptr);
}