Can anyone offer me some advice on how they deal with debugging plugins that fail to load (specifically in JUCE plugin host)
I’m getting different results between Windows and Linux for a plugin I am working on. The Linux build is causing a seg fault on plugin delete (separate issue) whilst the Windows build refuses to load.
I’m trying to get to the bottom of where the issue lies. If anyone can offer some times for debugging this problem/a non-loading plugin I’d really appreciate it.
Ok, so I’ve discovered the root of the problem. Projucer cock up on my part.
Would still be interested to know if people have any go to’s for plugins that do not load. Other than debugging the host I guess.
I would chuck a breakpoint on the entry point to see if it get’s hit at all. After that I would say it’s debugging the host, comparing it to other working plugins, looking for logs of any kind, check the console output when attached, check and clear blacklists, try and replicate the problem with another project - particularly one that works so you can work backwards, check other configurations i.e. is the problem in release builds only therefore try to gradually turn the debug build into a release build one change at a time.
All sound advice I will keep in mind for the future.
I had a plugin where on specifically for x64 release windows I had arch:AVX turned on, for some reason. This resulted in plugins not being loaded on setups with older cpu’s. No crashes however, and no debug breakpoints ever hit. Obviously I couldn’t reproduce anything on my own machine, so I had to get out of my way to acquire an older one.
I discovered that if you have fatal hardware or software exceptions during DLL initilization & load (ie., before any of “your” code ever runs), the loading process will crash and silently fail, resulting in the plugin not being “discovered”. In this case it was a hardware illegal instruction exception from the cpu. Not all code debuggers break on this, so I had to bring out assembly debuggers like OllyDBG.
In reality, every host can easily see it and do initiate the loading process, however the debug reporting on plugin loading errors from hosts are virtually non-existant.
Tips for Windows:
You can place a messagebox in the plugin creation code to get a chance to attach the debugger before any bad code runs (and in general verify the plugin creater code runs). Since Windows DLLs doesn’t carry metadata like on OS X, every host has to load and open every candidate DLL recursively so if your breakpoint still isn’t hit, either your exporting is wrong, mangled or missing or your architechture is wrong - or the DLLs dependencies are missing (commonly, making release builds with dynamically binded CRT dlls). There are other exceptional cases like my case above.
On OS X there are so many possible issues due to all the metadata, resources and executable formats that usually creating a project from scratch/forking something that works seems to take less time.