Skip to content
This repository has been archived by the owner on Jan 13, 2024. It is now read-only.

Packaged App Fails to find/load native addon #471

Closed
ghost opened this issue Jul 16, 2018 · 5 comments
Closed

Packaged App Fails to find/load native addon #471

ghost opened this issue Jul 16, 2018 · 5 comments
Labels

Comments

@ghost
Copy link

ghost commented Jul 16, 2018

Greetings,

I have followed the config guidelines and have updated my "package.json" file to include the "scripts" directive so that the .js files can be located in the packaged files, I also have my ".node" add on files in the same directory as my .exe (I am assuming the user guide steps to "include addon files in the same directory as the executable to mean just that?).

When I run my exe I get the following:

C:\git\appserver\server\src>view.exe
pkg/prelude/bootstrap.js:1176
throw error;
^
Error: Invalid access to memory location.
\?\C:\git\appserver\server\src\winutilsjs.node
at Object.Module._extensions..node (internal/modules/cjs/loader.js:729:18)
at Module.load (internal/modules/cjs/loader.js:610:32)
at tryModuleLoad (internal/modules/cjs/loader.js:549:12)
at Function.Module._load (internal/modules/cjs/loader.js:541:3)
at Module.require (internal/modules/cjs/loader.js:648:17)
at Module.require (pkg/prelude/bootstrap.js:1157:31)
at require (internal/modules/cjs/helpers.js:20:18)
at setupWindowsUtils (C:\snapshot\src\routes\main.js:0:0)
at Object.initialize (C:\snapshot\src\routes\main.js:0:0)
at Object. (C:\snapshot\src\server.js:0:0)
at Object. (C:\snapshot\src\server.js:0:0)
at Module._compile (pkg/prelude/bootstrap.js:1252:22)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:711:10)
at Module.load (internal/modules/cjs/loader.js:610:32)
at tryModuleLoad (internal/modules/cjs/loader.js:549:12)
at Function.Module._load (internal/modules/cjs/loader.js:541:3)

It looks like the application .exe is failing when it tries to load/use one of my addons. My application runs properly when not packaged, but fails when packaged. Any thoughts?

@ghost
Copy link
Author

ghost commented Aug 29, 2018

I found this issue #22099 in a different forum, I thought what the heck, i'll give it a shot. When I renamed my packaged file from "bview.exe" to "node.exe", my application started up and is running without any problems. I am still doing some testing to ensure all is good, but this looks promising.

I have an issue with having to rename my application to "node.exe" hopefully that will be addressed in the issue mentioned above, or perhaps PKG can fix this, I am not really sure where the "problem" originates.

Hope this information is useful to everyone.

@ghost
Copy link
Author

ghost commented Sep 4, 2018

Back to issue #22099, I received a response from a member. The basic premise "I believe" from the response, is that on Windows "..symbols are resolved by executable name..." and since the addons are complied against node.exe, when PKG outputs a custom name "bview.exe" for example, the addons don't know how to resolve symbol lookup since they are expecting "node.exe".

I don't completely buy this, as the PKG example, and simple test by me proved that I can load addons to a PKG packaged application using a name other than "node.exe" for the PKG name. But the addons I am having issue with are more "complex" and perhaps the suggestion has merit.

I also wonder if this has anything to do with PKG requirement that node addons cannot be packaged into the executable and have to be hosted outside the packaged application and this cross-boundary scenario is causing the issue?

@s-h-a-d-o-w
Copy link

s-h-a-d-o-w commented Jun 8, 2019

It's been a while but if you're still interested, there's this workaround of patching native addons. Works well for me.

I've also noticed that this isn't required for all native addons. Somewhere, I read that it's only necessary if the native addon makes use of node itself. (Personally, if I was to start a bigger project now, I'd probably write something that searches the whole project dir for .node files (and possibly .dll), copies them all to my output directory and blindly tries to patch all of them.)

@github-actions
Copy link

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label

@github-actions github-actions bot added the Stale label Apr 14, 2021
@github-actions
Copy link

This issue is now closed due to inactivity, you can of course reopen or reference this issue if you see fit.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant