vivify-server crashes: Segmentation fault

[Praczet]

Description

The vivify-server crash happens each time when I try to run

• viv [with file / without]
• viv --version
• vivify-server

To Reproduce

Just by running command

Context

My operating system is:

• OS: Manjaro Linux x86_64
• Host: XPS 13 9310 2-in-1
• Kernel: 6.1.105-1-MANJARO
• Shell: zsh 5.9
• GNOME 46.4
• Terminal: WezTerm / but also tested in gnome-terminal
• CPU: 11th Gen Intel i7-1165G7 (8) @ 4.700GHz
• GPU: Intel TigerLake-LP GT2 [Iris Xe Graphics]
• Memory: 4529MiB / 15710MiB

Running viv --version outputs:

Fatal: vivify-server crashed. Please use the link below to submit a bug report.

The bug report template will help you provide the necessary information and
maybe even find a solution yourself.

https://github.com/jannis-baum/Vivify/issues/new?labels=type%3Abug&template=bug-report.md

/home/adam/.local/bin/viv: line 73: 20499 Segmentation fault      (core dumped) nohup vivify-server $@ > "$output" 2> /dev/null

I've installed Vivify in the following way (e.g. name of the package manager, self-compiled or development mode):

• pacman,
• then yay
• then by cloning (./configure ~/.local/bin & make install

This is what happens when I kill any running instance of Vivify with killall vivify-server and then run vivify-server at the absolute installation path (e.g. at command -v vivify-server) instead of viv and try to reproduce the problem:
~/.local/bin/vivify-server

In the following I specify if I use any custom configuration, and if so provide it in its entirety including any additional files referenced there (e.g. CSS or JavaScript):

[tuurep]

Hi I'm the maintainer of the AUR packages

We've had a common issue building on Linux (Arch, as well as Fedora so far) with Node SEA, which is currently new and experimental. Building using system node would result in a segfaulting vivify-server executable on Arch and Fedora.

We managed to work around this issue by using the latest node from nvm (node version manager) when building.

So on Arch Linux, the way I build manually is this:

source /usr/share/nvm/init-nvm.sh
nvm use node

yarn install

./configure ~/.local/bin

make install

(above requires that nvm is installed)

The AUR packages (vivify, vivify-git) include the nvm step as a workaround and they're working for me on Arch.

So I'm wondering, is the issue that you're on Manjaro which introduces some subtle differences?

Also a possibility and a common mistake: be sure that you don't have an earlier instance of vivify-server running (which may be running even after you've uninstalled vivify). So run killall vivify-server and try if that resolves it.

Also if none of the above helps, I'd be interested if vivify-bin AUR package works for you.

[tuurep]

Another common mistake:

See that you're not using wrong executables by mistake,

For example, the AUR packages install in /usr/bin so this should look like this:

$ which viv
/usr/bin/viv
$ which vivify-server
/usr/bin/vivify-server

And at least for me, this takes precedence over ~/.local/bin so if I have an AUR-packaged vivify installed, but try to run a manually built one, it would mistakenly use the vivify-server installed by AUR.

[palomino79]

For anyone who still gets segmentation faults when using nvm use node - the most recently nvm node version for my system was 22.7.0, which was also causing segmentation faults. Installing and using node 21 with nvm allowed it to build and run vivify-server without issue.

[Praczet]

Thank you for the replay:

I tried what you suggested - I could run viv --version -> vivify-server v0.5.0, but server is not starting:

(node:15610) ExperimentalWarning: Single executable application is an experimental feature and might change at any time
(Use `vivify-server --trace-warnings ...` to show where the warning was created)

Then I uninstalled it, then installed vivify-bin
Same effect
Then I uninstalled it and installed: vivify-git
same effect (but different version of server:

 ~/Notes > viv eos-feat-Feedback.md                                                                                                                                                                         
Fatal: vivify-server crashed. Please use the link below to submit a bug report.

The bug report template will help you provide the necessary information and
maybe even find a solution yourself.

https://github.com/jannis-baum/Vivify/issues/new?labels=type%3Abug&template=bug-report.md

 ~/Notes  viv --version
vivify-server v0.5.0.r0.g9c5f1ff-1-aur
~/Notes > vivify-server eos-feat-Feedback.md                                                                                                                                                               
(node:25713) ExperimentalWarning: Single executable application is an experimental feature and might change at any time
(Use `vivify-server --trace-warnings ...` to show where the warning was created)

Best regards

source /usr/share/nvm/init-nvm.sh
nvm use node

yarn install

./configure ~/.local/bin

make install

[tuurep]

For anyone who still gets segmentation faults when using nvm use node - the most recently nvm node version for my system was 22.7.0, which was also causing segmentation faults. Installing and using node 21 with nvm allowed it to build and run vivify-server without issue.

Thanks, very good to know. Guess using the latest one is applicable to Arch but not for many other distros so I should be careful with the example 😄

@Praczet Yeah this seems pretty troubling.

The error message is improved a little bit in v0.5.1 and shows the full path of the crashing server, in case that would reveal anything but from what you say seems unlikely.

We've been talking about trying to run Manjaro in a VM and see if we can reproduce this and go from there. We'll be back to tell you how that's going 😄

[tuurep]

Oh yeah if anyone else is using Manjaro and would like to chime in, would be very helpful

[Tweekism]

I'm downloading Manjaro now to see if I can reproduce the error.

[Tweekism]

So I never know how much detail people want in a response like this, so first the short version:-

@Praczet, it looks like you might have both an AUR packaged version and a manually compiled (and broken) version installed. While you can have both versions installed, it does cause some confusion.

Lets see if we can get the AUR version going first...

Assuming you still have either vivify-git or vivify-bin installed from the AUR / yay can you:-

1. Update your AUR packages (we updated them to give some more error info)
2. Remove the broken manually built binaries: rm ~/.local/bin/viv*
3. Run viv again eg: viv . or viv /path/to/some/file.md

Can you let me know what happens?

If you do want to compile manually from source, we can fix that too. See below, and let me know if you want I can do step by step instructions to get you back into a working state. (just note I am in Australian Eastern time UTC+10 😅)

---

And for those interested, the deets!!!! -----

• Yes, I can reproduce this error using the manual build method and the Manjaro packaged version of nodejs
• The issue goes away when using the nvm version of nodejs nvm install node (if you do a clean rebuild, read on...)
• The system version of node and the nvm version of node are compiled differently even if they are the same version (eg: v22.7.0). To check which you are using, run command -v node, if it returns /usr/bin/node then that is the system version. The nvm version will return something like /home/jason/.nvm/versions/node/v22.7.0/bin/node
• When switching from the system version to the nvm version of node, you also need to run make clean or else make won't recompile all the things (Note: using nvm to switch to an older version of node like v21 will also likely trigger a rebuild, as the dependencies will have changed etc)
• If you just want to run vivify, you don't need to manually clone it down and run do the whole make install thing. Just doing sudo yay vivify-bin should be all you need

So, having said all that, you don't need to both install from the AUR and build from the git repo. One or the other is enough, and if you do build from source manually, you cannot use the Majaro (or Arch, or Fedora...) packaged version of node.

You need to install nvm and then do nvm install node then confirm it is pointing to the newly installed node command -v node or which node (as mentioned above) and then yarn then make clean and then make install

[Tweekism]

@jannis-baum This info is for you...

Manjaro

> objdump -p /home/jason/.nvm/versions/node/v22.7.0/bin/node | grep NEEDED      
  NEEDED               libdl.so.2
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libpthread.so.0
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2
> objdump -p /usr/bin/node | grep NEEDED 
  NEEDED               libz.so.1
  NEEDED               libuv.so.1
  NEEDED               libbrotlidec.so.1
  NEEDED               libbrotlienc.so.1
  NEEDED               libcares.so.2
  NEEDED               libnghttp2.so.14
  NEEDED               libcrypto.so.3
  NEEDED               libssl.so.3
  NEEDED               libicui18n.so.75
  NEEDED               libicuuc.so.75
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2

[tuurep]

Thanks very much!

When switching from the system version to the nvm version of node, you also need to run make clean or else make won't recompile all the things (Note: using nvm to switch to an older version of node like v21 will also likely trigger a rebuild, as the dependencies will have changed etc)

This seems significant to me

[Praczet]

@Tweekism

First of all thank you for dedicating time for this.
So I removed all instances and instalations of viv.
Then I:

• installed again vivify-bin -> error when running -> I removed
• installed again vivify -> error when running -> I removed
• git clone https://aur.archlinux.org/vivify.git -> makepkg -si
  (it seems that this build download node..)
• viv . -> again crashed:

atal: "/usr/bin/vivify-server" crashed.
Please use the link below to submit a bug report.

The bug report template will help you provide the necessary information and
maybe even find a solution yourself.

https://github.com/jannis-baum/Vivify/issues/new?labels=type%3Abug&template=bug-report.md

command -v node -> /usr/bin/node

[Tweekism]

Interesting, I'm out at the moment, I'll be home in 2 hours or so, and I have something else to try.

In the meantime, do you have nvm installed?

If so, can you nvm install node then a command -v node and post the output?

[Praczet]

Yes, I have it.

/home/adam/.nvm/versions/node/v22.7.0/bin/node

~/Notes  nvm install node
v22.7.0 is already installed.
Now using node v22.7.0 (npm v10.8.2)
~/Notes  command -v node
/home/adam/.nvm/versions/node/v22.7.0/bin/node

[Tweekism]

Ok cool.

Jannis is in the process of making some changes to the makefile to hopefully sort this out for good. Would you mind doing one more clean build using our repo?

so:-

• Remove all the viv's you have, confirm which viv returns nothing
• Clone a fresh copy our repo git clone https://github.com/jannis-baum/Vivify.git
• cd into that repo cd Vivify
• Make sure node is still pointing at /home/adam/.nvm/versions/node/v22.7.0/bin/node
• Then yarn
• then ./configure ~/.local/bin
• then make install

you can then run viv . At this point, I expect it to still crash. It'll be long but could you post the full output of all of this?

And then also for Jannis, could you run:-

objdump -p /home/adam/.nvm/versions/node/v22.7.0/bin/node | grep NEEDED

and

objdump -p /usr/bin/node | grep NEEDED

Every time I've ever hit this issue, the nvm version of node fixed it, so maybe this node dependency issue on your machine?

If you like, you can also then try using the older node version that @palomino79 used

So:-

• nvm install v21
• make clean
• yarn
• make install

then try viv again.

[Praczet]

install.log
yarn.log
hi,

1. which viv

viv not found

2. clone fresh copy, yarn, configure, make => done
3. viv . => crashed
4. The dump of ~/.../node

  NEEDED               libdl.so.2
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libpthread.so.0
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2

5. dump of /usr/bin/node

  NEEDED               libz.so.1
  NEEDED               libuv.so.1
  NEEDED               libbrotlidec.so.1
  NEEDED               libbrotlienc.so.1
  NEEDED               libcares.so.2
  NEEDED               libnghttp2.so.14
  NEEDED               libcrypto.so.3
  NEEDED               libssl.so.3
  NEEDED               libicui18n.so.75
  NEEDED               libicuuc.so.75
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2

So I tried:

nvm install v21
make clean
yarn
make install

viv . => crashes

[Edit]: I've attached two files: output for yarn and for make install

[Tweekism]

Ok let us have a look and see what we can find... :)

[Tweekism]

Hey, so we looked through your logs and notice you are missing a line that we all have. Specifically there should be a line that says Wrote single executable preparation blob to build/sea-prep.blob but its missing. Now that shouldn't matter if you are using pre-built binaries, unless the issue causing it to be missing is common to both building a nodejs single executable application and running one

So maybe we are looking at some runtime dependency issue for node itself?

If you are still happy to play along, could you do this?

EDIT: This should make it easier to copy and paste each command in order :)

ls -la /

cd /usr/lib &&
ls -l libdl.so.2 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libpthread.so.0 libc.so.6 ld-linux-x86-64.so.2

cd /usr/lib64 &&
ls -l libdl.so.2 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libpthread.so.0 libc.so.6 ld-linux-x86-64.so.2

And paste the whole output here?

Should look something like this:

 ~ > ls -la /      
total 104
drwxr-xr-x  17 root root  4096 Aug 21 11:18 .
drwxr-xr-x  17 root root  4096 Aug 21 11:18 ..
lrwxrwxrwx   1 root root     7 Apr  9 01:26 bin -> usr/bin
drwxr-xr-x   4 root root  4096 Aug 30 09:23 boot
-rw-r--r--   1 root root 21875 Aug 21 11:18 desktopfs-pkgs.txt
drwxr-xr-x  20 root root  3820 Aug 30 11:46 dev
drwxr-xr-x 119 root root 12288 Aug 30 14:46 etc
drwxr-xr-x   3 root root  4096 Aug 30 09:22 home
lrwxrwxrwx   1 root root     7 Apr  9 01:26 lib -> usr/lib
lrwxrwxrwx   1 root root     7 Apr  9 01:26 lib64 -> usr/lib
drwx------   2 root root 16384 Aug 30 09:20 lost+found
-rw-r--r--   1 root root     8 Aug 21 11:18 .manjaro-tools
drwxr-xr-x   2 root root  4096 Apr  9 01:26 mnt
drwxr-xr-x   2 root root  4096 Aug 30 09:23 opt
dr-xr-xr-x 350 root root     0 Aug 30 11:46 proc
drwxr-xr-x   7 root root  4096 Aug 30 09:44 root
-rw-r--r--   1 root root  5557 Aug 21 11:15 rootfs-pkgs.txt
drwxr-xr-x  31 root root   700 Aug 30 12:11 run
lrwxrwxrwx   1 root root     7 Apr  9 01:26 sbin -> usr/bin
drwxr-xr-x   4 root root  4096 Aug 21 11:14 srv
dr-xr-xr-x  13 root root     0 Aug 31 02:14 sys
drwxrwxrwt  15 root root   320 Aug 31 02:24 tmp
drwxr-xr-x   9 root root  4096 Aug 30 14:46 usr
drwxr-xr-x  12 root root  4096 Aug 30 11:40 var
 ~ > cd /usr/lib                      
 /usr/lib > ls -la libdl.so.2 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libpthread.so.0 libc.so.6 ld-linux-x86-64.so.2  

-rwxr-xr-x 1 root root  228376 Aug  6 06:00 ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 2014520 Aug  6 06:00 libc.so.6
-rwxr-xr-x 1 root root   14280 Aug  6 06:00 libdl.so.2
-rw-r--r-- 1 root root  915712 Aug  6 06:49 libgcc_s.so.1
-rwxr-xr-x 1 root root  973144 Aug  6 06:00 libm.so.6
-rwxr-xr-x 1 root root   14288 Aug  6 06:00 libpthread.so.0
lrwxrwxrwx 1 root root      19 Aug  6 06:49 libstdc++.so.6 -> libstdc++.so.6.0.33
 /usr/lib > cd /usr/lib64                                                                
 /usr/lib64 > ls -la libdl.so.2 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libpthread.so.0 libc.so.6 ld-linux-x86-64.so.2    

-rwxr-xr-x 1 root root  228376 Aug  6 06:00 ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 2014520 Aug  6 06:00 libc.so.6
-rwxr-xr-x 1 root root   14280 Aug  6 06:00 libdl.so.2
-rw-r--r-- 1 root root  915712 Aug  6 06:49 libgcc_s.so.1
-rwxr-xr-x 1 root root  973144 Aug  6 06:00 libm.so.6
-rwxr-xr-x 1 root root   14288 Aug  6 06:00 libpthread.so.0
lrwxrwxrwx 1 root root      19 Aug  6 06:49 libstdc++.so.6 -> libstdc++.so.6.0.33
 /usr/lib64 >

[Praczet]

Hey,

During the weekend I will little bit more sluggish...

I was pretty sure that I saw that message you mentioned... So I installed again and indeed this message was displayed on the screen, not redirected to the file..

Wrote single executable preparation blob to build/sea-prep.blob
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'

[Praczet]

OK.
So how to say it...

It works...

What changed?:

• I am at home (not in the office) different network
• I rebooted system.

I can check on Monday if it is related to network, in which I doubt.

Thank you very much for help. If you need something from me to check I will be more then happy to help you.
On Monday I will confirm if the vivify-server work.

Have a nice weekend.

[tuurep]

Great to know the build is the same with the sea-prep.blob!

Ok! Very nice, although not quite clear what fixed it but I think it's quuuite safe to say that Vivify works on Manjaro 😄

[Tweekism]

I can check on Monday if it is related to network, in which I doubt.

Awesome.

Sometimes corporate networks can block and do weird things, but I would have expected to see more obvious errors in that case.

So yeah, probably the restart. 😅

If I had to guess, maybe you had applied some updates and not rebooted yet?

Anyway, glad you got it working!

[jannis-baum]

Closing this then! Thanks a lot for all your work investigating this @tuurep @Tweekism

[Praczet]

Hi,
So how to say it :-(. I did not check on Monday if this works when I am connected to my work network. I've checked today. It doesn't work. Now at home I've checked and it works.
If needed I can do some tests tomorrow.

[jannis-baum]

Hey @Praczet sorry to hear that. I think at this point we can be quite certain that we can't reproduce this, so we can only help indirectly. My best guess right now is that your work network somehow keeps Node SEA ("Single executable application") from working, which is what we use to compile vivify-server into a single executable file for distribution.

If you want to keep investigating, you can follow this guide of creating a simple example Node SEA. In case my guess is right and this gives you the same error as you get with Vivify, you can contact the devs there to try and find a solution.

[Tweekism]

Hi, So how to say it :-(. I did not check on Monday if this works when I am connected to my work network. I've checked today. It doesn't work. Now at home I've checked and it works. If needed I can do some tests tomorrow.

Oh wow that is so interesting, so is it the building/compiling process that breaks at work? Or are you literally just trying to open the viewer on local files? I assume this is a laptop you are taking back and forth, is that correct?

[Praczet]

Hi,
@Tweekism yes I am just trying open the viewer on the same laptop.

I did some test today. As I said yesterday I am able to start and use vivify-server at home. At home I am connected thru Wired interface (as well as at the office). And at home it starts without no issues.

Today I came to office I tried to start server, it crashed. So I disabled the network interface and it started without any issue.

So it cashes only when I am connected (with active network interface) to my work's network. Even more when the server is active (activated with disabled network) I can active interface again and as long as I have active server (open tab with one of files) it works.

[jannis-baum]

@Praczet would you mind trying the Node SEA example that I sent in my previous reply? Without that we are just going in circles and guessing. Once you have tried this we will know if this happens because of how Node SEA works or because of some package we use for Vivify.

[Praczet]

@jannis-baum I will do it on Monday when I will be back at work.

[Praczet]

Hi,
I did as instructed and this is the result:

Start injection of NODE_SEA_BLOB in hello...
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
warning: Can't find string offset for section name '.note.100'
💉 Injection done!

Then running ./hello world gives:

Hello, world!
(node:7713) ExperimentalWarning: Single executable application is an experimental feature and might change at any time
(Use `hello --trace-warnings ...` to show where the warning was created)

So I think I managed to compile it.

[jannis-baum]

Hi Adam, thanks for trying this out. Our next best guess after this was that some package we use makes some network request and doesn't handle being blocked by your work network, but @Tweekism also ruled this out by monitoring the (lack of) network traffic that happens when Vivify starts.

With both of these guesses ruled out, it seems that the issue is caused by some other hard-to-predict thing that is blocked in your setup. This makes it very hard since we have no way of investigating other than asking you about every little thing, which would be very inefficient. For this reason I'll unfortunately have to tell you that we won't be able to keep looking into this – at least for now, unless it comes up again for someone else.

That said, you can of course keep looking into it yourself and we would be very happy to know about it in case you figure it out.

If I had access to your setup to keep investigating, I'd put together Vivify bit by bit (starting from the SEO example that works) and see what makes it break. My next best guess would be that it's the fact that we inject a ZIP file with the static assets into the executable (see Makefile) and read from it at runtime (see static router in source) to e.g. serve the CSS. Maybe your setup blocks reading that for some kind of security reason. So that's where I'd recommend to start looking in case you want to :)

[Praczet]

Thnx
For now "The season" at work just begun, so I won't have much time for investigating. As I said I can always for second switch off network interface and run vivify server and then switch on and it will work..

When I have time I will sit again and try to find the solution...
Can I ask why you put assets into a zip file and compile?

[jannis-baum]

Can I ask why you put assets into a zip file and compile?

On runtime we have to serve some static files (CSS, client-side JS and some other stuff) to make Vivify work and look nice on the browser. One way of doing this would be by making sure every user has all these files laying around somewhere on their machine, which would be quite cumbersome for (un)installation & support.

That's why we take all of these static files, compress them into a single ZIP archive (to save on storage), and add the binary data of this archive into the binary executable vivify-server. On runtime, we read from the section of the executable that has the ZIP data to retrieve the static files and serve them. This way there is no need for additional supporting files and vivify-server works by itself.

[Praczet]

Hi.
I had some time today. And I just realized that I didn't check what will happen if I change default port on which vivify works. I have changed to 8080 and it works on my work network. For some reason (which I do not understand) my work's network is blocking this port.

So now my mind can rest and I can close this "issue"

Still, thank you very much for the time you dedicated to me. I've never have so good feedback.