Azure-functions-host: Error when loading native node binary into job

[jamesdixon]

Hi, I'm trying to use a native Node library called Sharp (for image processing) in a webjob. The webjob is deployed as part of my Azure App Service instance and not as a Functions app.

When running the job, I get the following error:

Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: Functions.ProcessImages ---> System.Exception: Error: A dynamic link library (DLL) initialization routine failed.
 \\?\D:\local\Temp\jobs\continuous\scripthost\mvhbfltp.51e\ProcessImages\node_modules\sharp\build\Release\sharp.node at Error (native) at Object.Module._extensions..node (module.js:583:18) at Module.load (module.js:473:32) at tryModuleLoad (module.js:432:12) at Function.Module._load (module.js:424:3) at Module.require (module.js:483:17) at require (internal/module.js:20:19) at Object.<anonymous> (D:\local\Temp\jobs\continuous\scripthost\mvhbfltp.51e\ProcessImages\node_modules\sharp\index.js:12:13) at Module._compile (module.js:556:32) at Object.Module._extensions..js (module.js:565:10) at Module.load (module.js:473:32) at tryModuleLoad (module.js:432:12) at Function.Module._load (module.js:424:3) at Module.require (module.js:483:17) at require (internal/module.js:20:19) at Object.<anonymous> (D:\local\Temp\jobs\continuous\scripthost\mvhbfltp.51e\ProcessImages\index.js:11:15) at Module._compile (module.js:556:32) at Object.Module._extensions..js (module.js:565:10) at Module.load (module.js:473:32) at tryModuleLoad (module.js:432:12) at Function.Module._load (module.js:424:3) at Module.require (module.js:483:17)
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at Microsoft.Azure.WebJobs.Script.Description.FunctionInvokerBase.<Invoke>d__23.MoveNext()
 --- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.Azure.WebJobs.Host.Executors.FunctionInvoker`1.<InvokeAsync>d__0.MoveNext()
 --- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<InvokeAsync>d__53.MoveNext()
 --- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithWatchersAsync>d__3b.MoveNext()
 --- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithLoggingAsync>d__36.MoveNext()
 --- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithLoggingAsync>d__1a.MoveNext()
 --- End of inner exception stack trace ---
 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
 at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<ExecuteWithLoggingAsync>d__1a.MoveNext()
 --- End of stack trace from previous location where exception was thrown ---
 at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
 at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
 at Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.<TryExecuteAsync>d__2.MoveNext()

I'm running Node 6.9.1 x64 on Azure. When I compile the application on Appveyor, I'm also using Node 6.9.1 x64. Compilation works great, it's just the error above at runtime.

To be sure this wasn't an issue with the library itself, I created a test endpoint that utilizes the library in my main application and it works as expected.

Repro steps

Provide the steps required to reproduce the problem

1. Install 64-bit Node and setup app service to run it
2. Create a webjob that attempts to access the Sharp library.
3. Run the job

Expected behavior

The job runs without error.

Actual behavior

The job fails with the above error.

Related information

I'm running the Functions 1.0.10635 runtime, but have also tried with the previous version.

Here's a link to the source for the job: https://gist.github.com/jamesdixon/ba35960d7a64890eda49cc78a68cf424

Thank you!

[paulbatum]

@jamesdixon Have you tried using this library from a normal node.js web app hosted on AppService? There are known limitations with the sandbox around image/pdf processing, documented here. If the same error occurs for a standard web app then please close this issue.

[jamesdixon]

@paulbatum sorry if I was unclear, but when I said

To be sure this wasn't an issue with the library itself, I created a test endpoint that utilizes the library in my main application and it works as expected.

I was trying to communicate that I had used this library in my primary application hosted on App Service and it did indeed work.

Thank you!

[paulbatum]

@jamesdixon Ahh thanks, that makes sense.

[paulbatum]

One possibility that occurs to me - given you are running this job through the functions runtime, that means that you'll be using the version of Node.js built into functions, which is 6.5.0. Is it possible that this library does not work on 6.5.0?

[jamesdixon]

@paulbatum certainly a possibility, but I haven't seen anything to suggest it. I'll see if I can test using 6.5.

Good to know that functions uses a different version of Node!

[mamaso]

@jamesdixon Are you running with the 64 bit platform?

Can you also add a context.log(process.arch + " " + process.version); call to your function code so that we know which node process edgejs is running? In general, function apps will be ia32 v6.5.0.

If it's possible to build the Sharp library in 32 bit I expect these issues will resolve, x64 has not been tested as @davidebbo mentioned in the above stackoverflow post.

[jamesdixon]

@mamaso I haven't toyed with this in a while, but I believe I tried both 32/64 bit platforms. Sharp requires a 64-bit Node binary in order to run. I'm not sure if that means that I need to run the 64-bit platform as well?

At this time, it doesn't appear that Sharp supports 32-bit. It did at one point, but support is now gone.

[mamaso]

Ok, I've reproduced this error outside of the context of functions using only edgejs. I'll file a bug and see if I can dig more into the root cause.

[jamesdixon]

@mamaso thanks for looking into this. glad you were able to reproduce!

[paulbatum]

@mamaso Did you file the edgejs bug? I'm wondering if we can close this one?

[mamaso]

I filed an issue, it's not necessarily a bug.

Edge has some minimal documentation describing that 'native modules must be linked against the node.dll that edge uses'. I've tried various configurations with node-gyp and my own test native module to no avail on that front.

Even if that is successful, native modules will not work out of the npm install box - we or the user would need to rebuild the native module to link against edge's node.dll.

@christopheranderson seems to remember having some success with native modules & functions in the past (in particular bcrypt) so I've asked him to follow up with that.

[abramz]

This is quite old but still an open issue, are there any updates?