issue in node-6.10.2 capstan package

[ukeshkumar]

Hi,
I am trying to build image based on node-6.10.2. But by default it is taking node-4.4.5 also (for runtime node).
And while executing the the main js file, it is executing with 4.4.5 version instead of 6.10.2 version.

• Both node binary of version 4.4.5 & 6.10.2 are available in mpm-pkg/bin directory.
• node symbolic link in mpm-pkg directory is pointing to /bin/libnode-4.4.5.so

I have created node (symbolic link file) points to '/bin/libnode-6.10.2.so' file. I am getting the following error,
symlink /bin/libnode-6.10.2.so /home/ukesh/code/mpm-pkg/node: file exists

I am using the below,

• Capstan binary : http://x.k00.fr/3ub70 ->this is the latest Capstan binary (development branch)
• Packages downloaded using 'capstan pull' command

Could you please help me to resolve this issue ?

[miha-plesko]

Hi,

unfortunately runtime: node is bound to 4.4.5 at the moment. Could you please try to require the 6.10.2 package manually and then use runtime: native?

So in your meta/package.yaml:

name: demo
title: demo
author: me
require:
  - node-6.10.2  # <------ require node manually like this

and then in meta/run.yaml:

runtime: native
config_set:
  app:
    bootcmd: /node /my/server.js  # <------- this is what will be run
config_set_default: app

Please let me know if it works!

[ukeshkumar]

Hi @miha-plesko,

Thanks for the reply..

I am getting the below error now after trying the above one..

$ sudo capstan run ui
sudo: unable to resolve host ip-10-0-2-159
Empty command line will be set for this image
Created instance: ui
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
OSv v0.24-420-g9aba80a
eth0: 192.168.122.15

Aborted

[backtrace]
0x0000000000451e5a <osv::generate_signal(siginfo&, exception_frame*)+58>
0x0000000000451eca <osv::handle_mmap_fault(unsigned long, int, exception_frame*)+26>
0x000000000033043a <mmu::vm_fault(unsigned long, exception_frame*)+330>
0x0000000000395707 <page_fault+119>
0x0000000000394556 <???+3753302>
0x0000100001d2734f <icu_58::UnicodeSet::add(int, int)+127>
0x000010000130752d <icu_58::CollationDataReader::read(icu_58::CollationTailoring const*, unsigned char const*, int, icu_58::CollationTailoring&, UErrorCode&)+2093>
0x00001000013771c9 <icu_58::CollationRoot::load(UErrorCode&)+233>
0x00001000013772b7 <icu_58::CollationRoot::getRootCacheEntry(UErrorCode&)+87>
0x00001000012cc11e <icu_58::CollationLoader::loadTailoring(icu_58::Locale const&, UErrorCode&)+46>
0x000010000127b9c4 <icu_58::Collator::makeInstance(icu_58::Locale const&, UErrorCode&)+20>
0x000010000127ba56 <icu_58::Collator::createInstance(icu_58::Locale const&, UErrorCode&)+38>
0x0000100001956c55 <???+26569813>
0x000010000195916d <v8::internal::Collator::InitializeCollator(v8::internal::Isolate*, v8::internal::Handlev8::internal::String, v8::internal::Handlev8::internal::JSObject, v8::internal::Handlev8::internal::JSObject)+349>
0x0000100001af5753 <v8::internal::Runtime_CreateCollator(int, v8::internal::Object**, v8::internal::Isolate*)+1267>
0x00002a6c463092a6 <???+1177588390>
0x00002a6c465d07eb <???+1180501995>
0x00002a6c463400e2 <???+1177813218>
0x00002a6c46309894 <???+1177589908>
0x00002a6c46334455 <???+1177764949>
0x00002a6c4662e42f <???+1180886063>
0x00002a6c466af2b9 <???+1181414073>
0x00002a6c46449313 <???+1178899219>
0x00002a6c465f41b1 <???+1180647857>
0x00002a6c4643e571 <???+1178854769>
0x00002a6c4643e09c <???+1178853532>
0x00002a6c46434961 <???+1178814817>
0x00002a6c4648280b <???+1179133963>
0x00002a6c46449f05 <???+1178902277>
0x00002a6c466145b6 <???+1180779958>
0x00002a6c46449313 <???+1178899219>
0x00002a6c465f41b1 <???+1180647857>
0x00002a6c4643e571 <???+1178854769>
0x00002a6c4643e09c <???+1178853532>
0x00002a6c46434961 <???+1178814817>
0x00002a6c4648280b <???+1179133963>
0x00002a6c46449f05 <???+1178902277>
0x00002a6c4661370c <???+1180776204>
0x00002a6c46449313 <???+1178899219>
0x00002a6c465f41b1 <???+1180647857>
0x00002a6c4643e571 <???+1178854769>
0x00002a6c4643e09c <???+1178853532>
0x00002a6c46434961 <???+1178814817>
0x00002a6c4648280b <???+1179133963>
0x00002a6c46449f05 <???+1178902277>
0x00002a6c4644d548 <???+1178916168>
0x00002a6c46449313 <???+1178899219>
0x00002a6c4643f9aa <???+1178859946>
0x00002a6c4643e571 <???+1178854769>
0x00002a6c4643e09c <???+1178853532>
0x00002a6c46434961 <???+1178814817>
0x00002a6c4644a1d2 <???+1178902994>
0x00002a6c46449f05 <???+1178902277>
0x00002a6c464496f1 <???+1178900209>
0x00002a6c46449313 <???+1178899219>
0x00002a6c4643f9aa <???+1178859946>
0x00002a6c4643e571 <???+1178854769>
0x00002a6c4643e09c <???+1178853532>
0x00002a6c46434961 <???+1178814817>
0x00002a6c46434429 <???+1178813481>
0x00002a6c464342af <???+1178813103>
0x00002a6c46344955 <???+1177831765>
0x00002a6c46342738 <???+1177823032>
0x00002a6c4633b7a2 <???+1177794466>
0x00002a6c4632508e <???+1177702542>
0x00001000018bafc6 <v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, int, v8::internal::Handlev8::internal::Object)+198>
0x0000100001609af3 <v8::Function::Call(v8::Localv8::Context, v8::Localv8::Value, int, v8::Localv8::Value)+307>
0x0000100001613980 <v8::Function::Call(v8::Localv8::Value, int, v8::Localv8::Value*)+64>
0x00001000011fc74d node::LoadEnvironment(node::Environment*)+621
0x00001000011ff10f <node::Start(int, char**)+1247>
0x000000000041afc1 <osv::application::run_main(std::string, int, char**)+385>
0x000000000041d828 osv::application::run_main()+568
0x000000000020c5d6 osv::application::main()+86
0x000000000041db88 <???+4316040>
0x000000000044d185 <???+4510085>
0x00000000003f5547 <thread_main_c+39>
0x00000000003954d5 <???+3757269>

[miha-plesko]

Thanks for replying @ukeshkumar. It seems like unikernel is now built, but it crashes when your Node.js application is run (at some point). @justinc1 could you please skim through the error if your sharp eye sees something obvious?

@ukeshkumar it would be very helpful if you could share your Node.js file that crashes, so that we can reproduce. My guess is that one of npm libraries calls some system function that is not yet implemented in OSv... Did you make double sure that npm install was invoked on that exact Node.js version (i.e. 6.10.2)?

[miha-plesko]

I've tested just now with the simplest case, a console.log('Hello World'), and it seems to be working. So there must be some particular Node.js call that causes the crash.

[justinc1]

The 0x0000000000395707 <page_fault+119> part - this doesn't look like not implemented system function. Maybe some cross-compilation like problems?

• It would be worth to check libraries loaded in OSv VM at time of crash. But you need to have environment used to build capstan base image at hand (so that https://github.com/cloudius-systems/osv/wiki/Debugging-OSv#debugging-osv-with-gdb can be used - "osv syms" than shows info).

@ukeshkumar

• on what OS do you build capstan image?

[miha-plesko]

He's using our precompiled Capstan package node-6.10.2 without compiling anything, so there should be no cross-platform issues I guess.

@ukeshkumar may I ask you to perform these two steps (I'm attaching my output as well, you should get something similar):

1 - Compose unikernel

$ DISABLE_KVM=true capstan package compose my-unikernel
Command line will be set based on config_set_default attribute of meta/run.yaml
Resolved runtime into: native
Importing my-unikernel...
Importing into /home/miha/.capstan/repository/my-unikernel/my-unikernel.qemu
Uploading files to /home/miha/.capstan/repository/my-unikernel/my-unikernel.qemu...
Setting cmdline: --norandom --nomount --noinit /tools/mkfs.so; /tools/cpiod.so --prefix /zfs/zfs; /zfs.so set compression=off osv
Uploading files  38 / 38 [========================] 100.00% 0s
All files uploaded
Command line set to: 'runscript /run/hello;'

2 - Run unikernel

$ DISABLE_KVM=true capstan run my-unikernel
Empty command line will be set for this image
Created instance: my-unikernel
OSv v0.24-462-gd9a8771
eth0: 192.168.122.15
Hello World

Please let us know if you get anything strange.

[ukeshkumar]

Hi
I have checked that npm install was invoked on that exact Node.js version (i.e. 6.10.2).
I tried with 'DISABLE_KVM=true', this also not worked.

And I have tried sample hello world program in Node.js version 6.10.2, which is working.

[ukeshkumar]

The application has been written in Node.js version 8.4.0 and the team told that it should works fine with 6.10.2 (with warnings).
Could you please tell the steps to create package for Node.js version 8.4.0 ?
So that I can try with this version..

[miha-plesko]

Hi @ukeshkumar, could you please quickly test the application locally (on your machine, not on OSv) to see if it works on 6.10.2? If it works locally, then it's probably an issue on our side (missing OSv feature or something).

The "recipe" for preparing Node 6.10.2 package can be found here: https://github.com/mikelangelo-project/capstan-packages/blob/master/docker_files/recipes/node-6.10.2/build.sh. But let me try to compile 8.4.0 for you right now.

[miha-plesko]

Unfortunately there are some errors compiling node 8.4.0 and 8.9.4 package that I'm not sure how to resolve right now. Please let me know if it works on 6.10.2 locally. If it does, then we need to figure what line in your Node.js code causes the error to debug further. When I have some more time I'll try to prepare 8.9.4 package...

[ukeshkumar]

Yes.. it is working locally.

[ukeshkumar]

wio.zip
Hi @miha-plesko

Herewith attached sample nodejs project, even that also producing same trace. It would be great if you could help me in solving the issue..

[miha-plesko]

Thanks @ukeshkumar , I'll look into it.

[miha-plesko]

Hi @ukeshkumar, sorry for delay. I've been playing with your application today. My initial assumption was that there is some nasty npm dependency that needs to be npm install-ed on same Ubuntu version as the base unikernel was compiled on (14.04). So I booted up a Ubuntu 14.04 VM - and got the very same stacktrace as you're getting.

I think the problem is somewhere in OSv code itself, not the node package or Capstan, so I've opened an issue there: cloudius-systems/osv#940

Hopefully OSv authors will be able to resolve it...

[miha-plesko]

@ukeshkumar I'm not familiar with fuse-box, but is it possible to do the bundling in advance on your host machine and only put result into unikernel? So that fuse-box wouldn't be run in unikernel at all.

We're trying to debug what is causing problems to fuse-box, please see here.