Does Firefox disable plugins that failed to initialize? - linux

I am trying to test a Mozilla plugin (developed using FireBreath) in the form of an .so shared object file. The plugin was developed on Ubuntu, where it works fine.
I am now trying it under OpenSUSE - so I first symlinked the .so file in ~/.mozilla/plugins:
> ln -s /path/to/npXXX.so ~/.mozilla/plugins/
... and then ran Firefox (7) from command line:
> /path/to/firefox -P myprofile
...
LoadPlugin: failed to initialize shared library libXext.so [libXext.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /path/to/npXXX.so [/path/to/npXXX.so: undefined symbol: gtk_widget_get_mapped]
# and the LoadPlugin messages do NOT show a second time - probably because plugin is disabled (via about:addons).
And so I thought to try different stuff to look into this - but first, I restarted Firefox, and realized that on the second run I do not get the "LoadPlugin: failed to initialize" messages anymore! Then I tried removing the plugins symlink, and restarting FF; and adding it again, and restarting FF - still no error messages!
So, this tells me that probably Firefox somehow disabled/blacklisted the plugin (but which one: libXext, npXXX or both?) , but searching (grepping) for (np)XXX in '/path/to/myprofile/blocklist.xml' returns nothing (the plugin should use a email-like id, not those number GUIDs, so I'd expect that string to show in blocklist.xml if it's there).
Does anyone know: is the default behavior of Firefox to disable/blocklist plugins, that fail to load at first? If so, is there a way to force Firefox to load them again (and spit out error messages)? If you'd also have links to where this behavior is documented, it will be much appreciated :)
Many thanks in advance for any answers,
Cheers!
Note: after I stopped seeing the error messages, I did the following:
I am trying "about:plugins": "No enabled plugins found";
then trying "about:addons", and clicking under Plugins: "You don't have any add-ons of this type installed";
This plugin is not embedded in an extension, so nothing new should be added in "about:addons" under "Extensions" - and as expected, nothing new shows there. Under Ubuntu (where all works), just by symlinking the plugin to ~/.mozilla/plugins, the above two locations/screens start showing the plugin info.
This one of the things that puzzle me - if it just showed the plugin as "disabled", maybe I would have had a chance to re-enable it again (to get a new batch of error messages) - however, "about:plugins" and "about:addons" simply show nothing - so there's nothing I can use to enable from there. Which tells me Firefox has used a different method to disable the plugin(s) - but I cannot tell what it is...

Firefox has a cache for XPCOM modules ("fastload cache"), if a module fails to load Firefox won't try again. The cache is reset automatically if an extension is installed or if the application is updated. Starting with Firefox 4 you can also use -purgecaches command line flag to discard the cache.

Related

Gnome Shell Extensions: Errors when opening certain settings

Specifically, this is about ArcMenu and Blur my Shell. The former used to work, the latter never did. The extensions do what they're supposed to, but the settings menu never works. I tried uninstalling every gnome package, removing all extensions incl. Folders but nothing works...
ArcMenu error:
Error: No property header_suffix on AdwPreferencesGroup
Stack trace:
_init/Gtk.Widget.prototype._init#resource:///org/gnome/gjs/modules/core/overrides/Gtk.js:55:50
_init#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/settings/Menu/ThemePage.js:148:25
ArcMenu_SubPage#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/settings/Menu/SubPage.js:29:1
ArcMenu_ThemePage#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/settings/Menu/ThemePage.js:17:1
_addSubPageToRow#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/settings/MenuPage.js:162:29
_init#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/settings/MenuPage.js:56:14
ArcMenu_MenuPage#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/settings/MenuPage.js:22:1
populateWindow#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/prefs.js:30:22
fillPreferencesWindow#/home/nick/.local/share/gnome-shell/extensions/arcmenu#arcmenu.com/prefs.js:129:19
_init#resource:///org/gnome/Shell/Extensions/js/extensionPrefsDialog.js:27:29
ExtensionPrefsDialog#resource:///org/gnome/Shell/Extensions/js/extensionPrefsDialog.js:10:4
OpenExtensionPrefsAsync/<#resource:///org/gnome/Shell/Extensions/js/extensionsService.js:129:33
asyncCallback#resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
run#resource:///org/gnome/Shell/Extensions/js/dbusService.js:186:20
main#resource:///org/gnome/Shell/Extensions/js/main.js:22:13
run#resource:///org/gnome/gjs/modules/script/package.js:206:19
start#resource:///org/gnome/gjs/modules/script/package.js:190:8
#/usr/share/gnome-shell/org.gnome.Shell.Extensions:1:17
Blur My Shell Error:
Error: Argument object may not be null
Stack trace:
createCheckedMethod/<#resource:///org/gnome/gjs/modules/core/overrides/Gio.js:533:46
connect_to#/home/nick/.local/share/gnome-shell/extensions/blur-my-shell#aunetx/preferences/customize_row.js:72:11
General#/home/nick/.local/share/gnome-shell/extensions/blur-my-shell#aunetx/preferences/general.js:33:43
fillPreferencesWindow#/home/nick/.local/share/gnome-shell/extensions/blur-my-shell#aunetx/prefs.js:35:16
_init#resource:///org/gnome/Shell/Extensions/js/extensionPrefsDialog.js:27:29
ExtensionPrefsDialog#resource:///org/gnome/Shell/Extensions/js/extensionPrefsDialog.js:10:4
OpenExtensionPrefsAsync/<#resource:///org/gnome/Shell/Extensions/js/extensionsService.js:129:33
asyncCallback#resource:///org/gnome/gjs/modules/core/overrides/Gio.js:115:22
run#resource:///org/gnome/Shell/Extensions/js/dbusService.js:186:20
main#resource:///org/gnome/Shell/Extensions/js/main.js:22:13
run#resource:///org/gnome/gjs/modules/script/package.js:206:19
start#resource:///org/gnome/gjs/modules/script/package.js:190:8
#/usr/share/gnome-shell/org.gnome.Shell.Extensions:1:17
My OS is Linux Mint 21, Gnome Version 42.4, Windowing System Wayland (Errors the same on xorg), Device Lenovo ThinkBook 14s ITL Yoga.
I tried deleting ~/.local/share/gnome-shell/extensions, as well as /usr/local/share/gnome-shell/extensions, purging and autoremoving gnome* and gdm3, then reinstalling these two packages.
I hoped that would fix it, but naught. All my extensions even kept their settings.
Any help appreciated!

Sybase 16 startserver failed due to missing libsapcrypto.so

We've installed Sybase 16 Express in our Linux box, it was able to startup right after the installation. When we recently try restarting it with the startserver -f RUN_FILE command, it failed to find the libsapcrypto.so file.
~/sap/ASE-16_0/bin> ../sap/ASE-16_0/bin/dataserver: error while loading shared libraries: libsapcrypto.so: cannot open shared object file: No such file or directory
We searched this file, multiple matches presented in the following paths:
./DM/OCS-16_0/lib3p/libsapcrypto.so
./DM/OCS-16_0/lib3p64/libsapcrypto.so
./DM/OCS-16_0/devlib3p64/libsapcrypto.so
./DM/OCS-16_0/devlib3p/libsapcrypto.so
./DM/REP-16_0/lib64/libsapcrypto.so
./DataAccess/ODBC/lib/libsapcrypto.so
./DataAccess64/ODBC/lib/libsapcrypto.so
./OCS-16_0/lib3p/libsapcrypto.so
./OCS-16_0/lib3p64/libsapcrypto.so
./OCS-16_0/devlib3p64/libsapcrypto.so
./OCS-16_0/devlib3p/libsapcrypto.so
Since this hasn't been answered yet, running this command worked for me:
. /opt/sap/SYBASE.sh
Note the different syntax to make sure the environment variables are set in the terminal session, as opposed to using this syntax:
/opt/sap/SYBASE.sh

'SB-KERNEL:UNKNOWN-PARSE-TYPE' when connecting Vim to SBCL using Vlime

I have Vim 8.0.1365 with Vlime plugin (065b95f) installed and an SBCL (1.2.11) session with the start-vlime.lisp loaded, running on macOS 10.14.6 (18G87).
When I connect from Vim using \cc, the SBCL session shows vlime-sbcl - New connection from #<AIO-SBCL:AIO-FD {10048DFD63} (so the connection works) but then the debugger is invoked with an SB-KERNEL:PARSE-UNKNOWN-TYPE condition signalled.
The debugger restarts are:
0: [REMOVE-FD-HANDLER] Remove #<SB-IMPL::HANDLER INPUT on descriptor 6: #<FUNCTION AIO-SBCL::SOCKET-INPUT-CB>>
1: [ABORT ] Exit debugger, returning to top level.
(VLIME-SBCL::SOCKET-ERROR-CB #<unavailable argument> #<SB-KERNEL:PARSE-UNKNOWN-TYPE {1004BE9B23}>)
I've tried both restart options. Removing the handler gives no response, and aborting returns SBCL to the * prompt.
The connection appears to exist in Vim (though there is no success message) and can be selected when using the \ss command (I tested on (+ 3 3)).
The SWANK window just displays a -- for each use of \ss and an error message below shows:
Error detected while processing function vlime#plugin#SendToREPL[100]..vlime#ui#input#MaybeInput[33]..<SNR>42_CheckInputValidity[2]..<SNR>32_SendToREPLInputComplete:
line 2:
E716: Key not present in Dictionary: ListenerEval, [a:content, function('s:OnListenerEvalComplete')]))
E116: Invalid arguments for function(a:conn.ListenerEval, [a:content, function('s:OnListenerEvalComplete')]))
E116: Invalid arguments for function vlime#WithThread
I don't have much experience with SBCL or Lisp - this is basically a hurdle at the starting line.
What does the first restart option mean?
The PARSE-UNKNOWN-TYPE condition seems uncommon from a Google search, and not at all in relation to Vlime. What are some next steps I can take to work this out?
(Posting the comment as an answer)
A common source of error when dealing with client/server protocols is a mismatch in versions for the different parts involved. The gihub page for vlime lists dependencies and supported implementations, I'd start from there.
Also, try starting sbcl in a standalone terminal (first install quicklisp, use "rlwrap sbcl" for readline support) and then load Swank manually:
(ql:quickload :swank)
Create a server
(swank:create-server :port 4005)
And connect to it, so you can still debug errors from the terminal if there are problems with the client/server interface.

Error: EMFILE: too many open files on win

I was building an Vscode-like App, and I wrote my own extension to Vscode and put it into source code, it's work fine. But after I use gulp command to package my app, here is sth wrong :(On mac OS it's worked)
[17:07:59] Finished 'optimize-vscode' after 23 s
[17:07:59] Starting 'vscode-win32-x64'...
[17:08:31] Downloading extension: ms-vscode.node-debug2#1.25.6 ...
[17:08:32] Downloading extension: ms-vscode.node-debug#1.25.4 ...
events.js:183
throw er; // Unhandled 'error' event
^
Error: EMFILE: too many open files, open 'C:\Gitlab-Runner\builds\251c7da1\0\Haochen_super\IDE\extensions\hap-transformer\node_modules\qa-transformer\build\core\transformers\style\rules\declaration\dimension.js'
Can some one help me out on windows with this problem????
Not sure is this is the same problem or not, if it's - up vote my answer, if not - just continue to search.
When debugging with visual studio or visual code - visual studio keep logs of debugging session in file %TEMP%\vscode-node-debug2.txt.
It's indeed long log text, which is difficult to read and moreover understand what went wrong. But in my case I've found following log entry (somewhere close to the end of log):
↠From target: {"method":"Runtime.consoleAPICalled","params":{"type":"error","args":[{"type":"string","value":"WebpackO
ptionsValidationError: Invalid configuration object. Webpack has been initialised using a configuration object that does
not match the API schema.\n - configuration.context: The provided value \"D:\\\\!deleteme!\\\\VuejsApp1\\\\VuejsApp1\" co
ntains exclamation mark (!) which is not allowed because it's reserved for loader syntax.\n -\u003E The base directory
There were also a lot of EMFILE log entries, but they were not a root cause of failure.
Root cause in my case was that I have used special character in path - D:\!deleteme!\VueJsApp - and I have fixed it by simply creating directory without exclamation mark.
I was still not being able to debug VueJsApp - I suspect due to .vue to .js conversions, but normal javascript was possible to debug still.

Error grabbing Grapes ... unresolved dependency ... not found

UPDATE 8/6:
The beefed up logging has shown me that there is an issue deleting the old jar from the cache, which leads to the fatal "not found" error. There are other threads similar to this, but only when someone is locking the file with their IDE. We are running a single groovy script from Jenkins, and no one is logged into this box.
We ran process explorer right after the failure and there were no locks. Then I login with the user that Jenkins is using to run the script, and I get no error deleting the files.
Also it seems there was a fix in IVY 2.1 to not fail when the jar cannot be deleted, and I'm on Ivy 2.2 (Groovy 1.8.4). What gives?
Couldn't delete outdated artifact from cache: C:\Users\myUser\.groovy\grapes\com.a.b.c\x-y-z\jars\x-y-z-1.496.jar
then the false(?) error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
at smokeTestSuccess.<clinit>(smokeTestSuccess.groovy)
Interestingly enough, this happens everyday the first time the script is run after 5am. I guess the cache gets invalidated through some default config at 5am? Is this some kind of clue??
Original post:
I am intermittently getting an error when running a number of different Groovy scripts which all share an identical #Grab declaration. (file names changed to protect the innocent). First the full Grab declaration:
#GrabResolver(name = 'libs.release', root = 'http://myserver:8081/artifactory/libs-release', m2compatible = 'true') #Grapes([
#Grab(group = 'com.a.b.c, module = 'x-y-z', version = '1.+', changing = true),
#Grab('commons-lang:commons-lang:2.3'),
#Grab('log4j:log4j:1.2.16'),
#Grab('gpars:gpars:0.12'),
#Grab('jsr166y:jsr166y:1.7.0'),
#Grab('org.codehaus.groovy.modules.http-builder:http-builder:0.6'),
#Grab('org.apache.commons:commons-collections:3.2.1'),
#Grab('org.apache.httpcomponents:httpclient:4.2.2'),
#Grab('org.apache.httpcomponents:httpcore:4.2.3'),
#Grab('org.cyberneko.html:nekohtml:1.9.17'),
#Grab('xerces:xercesImpl:2.11.0'),
]) #GrabConfig(systemClassLoader = true)
Then the error:
Caught: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: Error grabbing Grapes -- [unresolved dependency: com.a.b.c#x-y-z;1.+: not found]
Upon doing numerous internet searches, the cause always seems to be very simple, either one of these two basic problems:
1. Repository unreachable
2. Jar file doesn’t exist
However, in the artifactory logs, I've proven that the file is actually being downloaded:
*Artifactory did accept the request for download:
2014-07-17 07:58:19,938 [ACCEPTED DOWNLOAD] libs-release-local:com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar for anonymous/165.226.40.155.
*Artifactory did deliver jar:
20140717075820|156|REQUEST|165.226.40.155|non_authenticated_user|GET|/libs-release/com/a/b/c/x-y-z/1.477/x-y-z-1.477.jar|HTTP/1.1|200|1276695
The scripts all work about 100% of the time if they are simply restarted. This all leads me to believe that the issue is the Grab timing out. Theoretically the second time I run the script, the file is in the cache, and things happen faster, thus it doesnt fail.
For the above real request, I can see about 20 seconds of elapsed time in the http log from request to download.
Questions:
Does my theory seem correct?
Is there a way to increase the amount of time that the script will wait for the #Grab to resolve?
Does putting a try / catch block around the #Grab statements seem like a good idea? Or will that just hide the real problem?
thanks in advance!!!!
I think I finally figured out the answer to my own question.
I believe there is some sort of bug within Groovy 1.8.4 (or Ivy 2.2), especially since this behavior does mirror an ancient documented Ivy bug with this exact error message scheme and behavior.
Upgrading to Groovy 2.3.6 (which includes Ivy 2.3) appears to solve the issue.
I also still have no idea why the jars cannot be deleted, nothing is locking them. I experimented with moving the grape cache to a less secure folder to rule out a permission issue, but this didn't help:
-Dgrape.root=D:\Temp\grapeCache
UPDATE 8/19:
Once we upgraded to Groovy 2.3.6, the error went away, but I then figured out that the jar was no longer being downloaded at all, when using the "1.+" resolver. Something in the defaultgrapeConfig.xml was causing an issue. Everything is finally working properly after (in addition to the Groovy upgrade) we overrode defaultgrapeConfig.xml with our own stripped down file using this command line JAVA_OPT:
-Dgrape.config=D:\Temp\myGrapeConfig.xml
which had these contents:
<ivysettings>
<settings defaultResolver="downloadGrapes"/>
<resolvers>
<chain name="downloadGrapes">
</chain>
</resolvers>
</ivysettings>
ALSO:
For completeness (further steps):
In Jenkins GUI, update the job(s):
a. Update the drop down for each script: Execute Groovy Script > Groovy Version > Groovy-2.3.6
b. Update the JAVA_OPTS for each script (have to click the ‘advanced’ button under the script to see JAVA_OPTS):
-Dgrape.config=D:\Software\SfGrapeConfig.xml
Optional logging switches: -Dgroovy.grape.report.downloads=true -Divy.message.logger.level=4
In the actual Groovy script itself, delete this option within the #GrabResolver annotation: , m2compatible = 'true'
If you get this or a similar error:
"could not find client or server jvm under [Whatever JAVE_HOME is], please check that it is a valid jdk / jre containing the desired type of jvm"
Delete groovy.exe & groovyw.exe from D:\Software\Groovy-2.3.6\bin (if the exe’s do not exist, the Jenkins groovy plugin will use the bat file versions of these, and they handle the 32-bit / 64-bit problem better than the exe’s)

Resources