plug ins not showing in 4.80, one one laptop, work on another?

[rgleason]

I guess it's unlikely this is some part of Pavel's plugin Blacklist code?

[transmitterdan]

Originally Posted by rgleason

I guess it's unlikely this is some part of Pavel's plugin Blacklist code?

No, it does not appear to be that.

[Hakan]

Originally Posted by transmitterdan

Hakan,

Can you find a way to get the offending subdirectories zipped up and send them to me? If so, send a PM as to best way to send them to me.

I will investigate what happened and may be able to get O to work around this.

Changing the search path won't fix it for all users.

Probably what happens is the plugin initially loads without issues. Then when O tries to use the plugin it gets upset and throws an exception. The wxWidgets library has a global exception catch which O handles by printing the message you see in the log file. It probably happens at the point O is asking the plugin for it's description. Perhaps some data file the plugin needs is missing or corrupted. If we can corner this issue then we can find a permanent solution.

TDan..
OK I can agree it may not be the final solution but still:
1)
Why are we searching in plugins subdirectories in Windows run time, not debug? I thought all dll's are expected to be found in \plugins\ only?
2)
The method I used to get into the blank tab and freeze was to:
-Make a directory "test" in \plugins\
-Copy oeSENC_pi.dll to \plugins\test\.
-Renamed the file to oeSENC2_pi.dll
-Started O with your patch opencpn.exe -d
Then when I went into options-Plugins and got the question about loading \test\oeSENC2_pi.dll I answered Yes.

Try that and see if get the same result.

The S63_pi directory must be something the S63 installation has done. See if you've the same. I'll look further into that.

Håkan

[transmitterdan]

I think it does not matter where the "bad" plugin is found. It can be in "plugins" or some sub-folder.

[Hakan]

Sorry to be obstinate but why search in subdirectories in Windows? What plugins would be stored there?

[rgleason]

1. I tend to agree with Hakan, but don''t know enough.... I think we should assume the plugins land in the proper directory... or its a user/plugin error, besides there are enough things going on, shouldn't all plugins run out of a given directory?
2. Hakan, that's quite abusive. What Windooows user is going to do that kind of stuff, many are very nervous doing anything at that level. If someone does that, they should know what they are doing, or is that your point. - Can't protect against that stuff...

Maybe the searching is because of other OS like Linux??

TDan..
OK I can agree it may not be the final solution but still:
1) Why are we searching in plugins subdirectories in Windows run time, not debug? I thought all dll's are expected to be found in \plugins\ only?
2) The method I used to get into the blank tab and freeze was to:
-Make a directory "test" in \plugins\
-Copy oeSENC_pi.dll to \plugins\test\.
-Renamed the file to oeSENC2_pi.dll
-Started O with your patch opencpn.exe -d
Then when I went into options-Plugins and got the question about loading \test\oeSENC2_pi.dll I answered Yes.

[transmitterdan]

Originally Posted by Hakan

Sorry to be obstinate but why search in subdirectories in Windows? What plugins would be stored there?

For this issue it matters not where the dll is found. I think there are some plugins that put the dll down a folder. There is nothing wrong with that in itself. In fact, it could be considered a good practice to do that. It would avoid file name clashes. That is not the root problem.

The root problem is that a dll passes all the tests and appears to be a valid dll. But it appears at some point it causes the windows runtime library to throw an exception which bubbles up to wxWidgets. That's why you see the message about unhandled exception in the log file. It has nothing to do with what folder the dll was found.

[bdbcat]

Hakan...

I cannot reproduce your "test" scenario. It all works fine, although loading two identical plugins (different in name only) is likely to cause trouble eventually.

I agree with TDan: a dll is a dll, wherever it comes from. There is no reason to insist that plugin dll's must be in the root of the plugins folder .

The question is: exactly which plugin produces the "Varning..."?
Is it caused by a "duplicated" plugin load, perhaps from a prior version hiding in a subdirectory?
And does it depend on load order, or the particular plugin mix prior to the error message?

I suspected logbookkonni, but this works fine on my Win7 machine, no matter when it gets loaded....


Since you can reproduce the fault in some reproducible way, please try some variations to try to isolate it further.

Thanks
Dave

[transmitterdan]

Dave,

I "almost" have it reproduced in a debug setup. But every time I think I have it cornered and switch to a Release build then O does the right thing every time. But I am getting closer. Still I would like to have a copy of the entire plugin folder from a machine that has the problem.

[Hakan]

Dave..TDan..
Ok, thanks for the subdir. explanation. Convinced.

My test\oeSENC failure seems to be a occasional scenario. It's not repeatable. And I'm sorry I've no access to a repeatable failure subdir. My friend user is still on vacation.

A note for what it can be worth:
If I answer "No" to "Shall we load plugin file....." when entering options-plugins tab the plugin list is empty and sometimes O freezes. I know this has nothing to do with a real run since it's a debug method but when I answer "No" the method CheckPluginCompatibility(wxString plugin_file) return "False" and the plugin list is empty.
Could it be that the "CheckPluginCompatibility" can return "False" without a blacklist note for other reasons?

Anything else I can do?

Håkan

[transmitterdan]

Hakan,

If you are going to answer NO to the load plugin query then you have to do that twice for enabled plugins. The first time it asks when O starts answer NO to all of them. Then there should be no issue when you answer NO after clicking the Plugin tab. So try answering NO to all queries about loading a plugin. Does O still freeze?

I think this could be a clue to part of the problem. If a plugin is successfully loaded when O starts but then is not loaded again when the Plugin tab is clicked that could leave O in a somewhat confused state.

[transmitterdan]

Originally Posted by Hakan

Could it be that the "CheckPluginCompatibility" can return "False" without a blacklist note for other reasons?

Håkan

Yes, O tries to examine several details of the DLL structure to make sure it looks like a real plugin. If any of these tests fail then it will act as if the plugin is in the "blacklist". We suspect it is this examination that needs to be more thorough so "bad" plugins don't load. Some old plugins are built with an old version of WxWidgets for example. So O checks which version the plugin expects and if it is an old one then it flags it as incompatible.

My "guess" what is happening is that some plugin is found and meets all the validity tests, but that plugin is missing some data file or a data file is corrupted. The plugin does not gracefully handle the missing data and triggers an exception (possibly null pointer). This causes O to abandon the plugin loading process before it is complete. So far, every case I have seen involves a user with remnants of an old installation in the plugins folder. I suspect that to be the case every time. Thus my advice to uninstall O, delete any remaining old plugins files and then install O again.

[rgleason]

This may be a side issue or it may not. Plugin API
but in any case I'd like to know what we should do.

pi113 (1.13) = OpenCPN 4.1 <—wxWidgets 3.0.2 used
pi113 (1.13) = OpenCPN 4.2 ←SVG Icons added (gtk,expat,vc,etc)

If a plugin is compiled with 'opencpn.lib' from Opencpn v4.1
it uses wxWidgets 3.0.2 but not SVG Icons.

If a plugin is compiled with 'opencpn.lib' from Opencpn v4.2
it uses wxWidgets 3.0.2 and also SVG Icons.

Is there a problem compiling plugins for Opencpn v4.1 now?
What are the problems? - Just that SVG does not work?

Is there a mandate that to compile plugins we should now use only
'opencpn.lib' from Opencpn v4.2 (as the "oldest" useful version)?

What exactly does blacklist look for with regard to wxWidgets and SVG in a plugin to confirm compatibility?

[Hakan]

Originally Posted by transmitterdan

Yes, O tries to examine several details of the DLL structure to make sure it looks like a real plugin. If any of these tests fail then it will act as if the plugin is in the "blacklist". We suspect it is this examination that needs to be more thorough so "bad" plugins don't load. Some old plugins are built with an old version of WxWidgets for example. So O checks which version the plugin expects and if it is an old one then it flags it as incompatible.

My "guess" what is happening is that some plugin is found and meets all the validity tests, but that plugin is missing some data file or a data file is corrupted. The plugin does not gracefully handle the missing data and triggers an exception (possibly null pointer). This causes O to abandon the plugin loading process before it is complete. So far, every case I have seen involves a user with remnants of an old installation in the plugins folder. I suspect that to be the case every time. Thus my advice to uninstall O, delete any remaining old plugins files and then install O again.

TDan..
Thanks, good explanations and your work here is appreciated.
The blacklist procedure is well known and functional. Also is it messaging the user what's wrong. That procedure is working fine during initialization and if a not activated bad plugin is found when options-plugin tab is opened.
But as you say if an already loaded plugin is found also as an older version in a subdirectory when plugins tab is opened there can for sure be problem. And no user info is prepared for that.

So, what to do? If the user visit the forum it's no problem but most won't. He'll sit with an empty plugins tab and don't understand what to do. If we will continue searching also in subdirectories a method to info the user about appropriate actions or which dll is causing the trouble would be fare.
Is it possible to catch the file name and path and message if we come to the "Caught MainLoopException, continuing.."?
Another (extremely time consuming?) ruff way would be to write every path/file to the log file while searching and delete that row again if succeed.

We may have come to an end with this? But if I could catch a plugins directory with a known failure next week, would you still need it?
Håkan

[bdbcat]

Hakan....

Appreciate your thoughts and comments.

I think TDan's possible analysis is the most likely suspect now. Some old file matching "*_pi.dll" is being found in the plugins tree, is validated, and is thus loaded. But that plugin is broken in some subtle way, or breaks an already installed plugin.

So, if you can catch a failure when you friend returns next week, by all means we would like to see the contents of the plugin subdirectories.

Thanks
Dave