OpenBSD: MAP_STACK and sanitizeStackForVMImpl

[baulig]

I am probably one of the very few people who are trying to run this on OpenBSD and fully understand that this is not currently a supported platform.

However, I had successfully used some of the preview releases and really liked what I saw.

Unfortunately, the 3.0.0 release immediately crashes on startup due to what's either a bug or incompatibility in sanitizeStackForVMImpl() from libjavascriptcoregtk-4.1.so.3.8.

Before we dive any further into this - that library comes from

[martin@gondor:martin % 2] $ /usr/sbin/pkg_info -E /usr/local/lib/libjavascriptcoregtk-4.1.so.3.8 
/usr/local/lib/libjavascriptcoregtk-4.1.so.3.8: webkitgtk41-2.40.1p0
webkitgtk41-2.40.1p0 GTK+ port of the WebKit (4.1) rendering engine

Is that the correct version of WebKit? OpenBSD 7.3 also ships with these versions:

webkitgtk40-2.38.5
webkitgtk41-2.38.5
webkitgtk50-2.38.5

Unfortunately, the Developer's Manual isn't quite clear about the particular version of WebKit that's needed.

---

The crash happens because OpenBSD requires all pages that are used for the stack to be mapped via MAP_STACK. There's a good article about that here.

The "CORRUPTION WARNING" message seems to be from the OS prior to killing the process:

[martin@gondor:nyxt % 9] $ ./nyxt --failsafe --verbose
Arguments parsed: (FAILSAFE T VERBOSE T URLS NIL) and NIL
Nyxt version 3.0.0-1-g7e7fe4ddd
 <INFO> [08:49:38] nyxt start.lisp (start-browser) -
  Source location: #P"/Workspace/nyxt/"
 <INFO> [08:49:38] nyxt start.lisp (start-browser) - Profile: "nofile"
<DEBUG> [08:49:38] nyxt/renderer/gi-gtk gi-gtk.lisp (ffi-initialize gi-gtk-browser) -
  Initializing GI-GTK Interface
<DEBUG> [08:49:38] nyxt/renderer/gtk gtk.lisp (ffi-initialize gtk-browser) -
  Initializing GTK Interface
<DEBUG> [08:49:38] nyxt configuration.lisp (current-buffer) -
  No active window, picking last active buffer.
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 927 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 928 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 929 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 930 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 931 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) -
  Registering callback 932 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) -
  Registering callback 933 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 934 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 935 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 936 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 937 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 938 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) -
  Registering callback 939 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) -
  Registering callback 940 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
<DEBUG> [08:49:39] nyxt urls.lisp (lisp-url with-recursive-lock-thunk) - Registering callback 941 for buffer #<STATUS-BUFFER 839 {10093A9CF3}>
CORRUPTION WARNING
Memory fault(coredump)

I'm also getting the following in dmesg:

map stack for pid 50707 failed
[nyxt]50707/246236 sp=205706000 inside 220480000-22075ffff: not MAP_STACK

Stack trace:

#0  0x000000023d111be0 in __vfprintf (fp=0x258c40, fmt0=0x20cae8 " in SBCL pid %d pthread %p", ap=Unhandled dwarf expression opcode 0xa3
) at /usr/src/lib/libc/stdio/vfprintf.c:127
127		_FILEEXT_SETUP(&fake, &fakeext);
(gdb) bt
#0  0x000000023d111be0 in __vfprintf (fp=0x258c40, fmt0=0x20cae8 " in SBCL pid %d pthread %p", ap=Unhandled dwarf expression opcode 0xa3
) at /usr/src/lib/libc/stdio/vfprintf.c:127
#1  0x000000023d111ac6 in _libc_vfprintf (fp=0x258c40, fmt0=0x20cae8 " in SBCL pid %d pthread %p", ap=0x205705880) at /usr/src/lib/libc/stdio/vfprintf.c:263
#2  0x000000023d17636c in _libc_fprintf (fp=Unhandled dwarf expression opcode 0xa3
) at /usr/src/lib/libc/stdio/fprintf.c:44
#3  0x000000000022470d in corruption_warning_and_maybe_lose ()
#4  0x00000000002271f6 in lisp_memory_fault_error ()
#5  0x000000000022697d in low_level_handle_now_handler ()
#6  0x00000002900def6d in _ZN3WTFL16jscSignalHandlerEiP9siginfo_tPv () from /usr/local/lib/libjavascriptcoregtk-4.1.so.3.8
#7  <signal handler called>
#8  0x000000028ec519ca in sanitizeStackForVMImpl () from /usr/local/lib/libjavascriptcoregtk-4.1.so.3.8
Cannot access memory at address 0x205706000

Looking at the registers in that frame reveals that rbp is within the stack range, rsp is not:

rax            0x205706000	8681185280
rbx            0x0	0
rcx            0x205706000	8681185280
rdx            0x0	0
rsi            0x205706000	8681185280
rdi            0x22066eab8	9133550264
rbp            0x22066eb20	0x22066eb20
rsp            0x205706000	0x205706000
r8             0x0	0
r9             0x2eaec0700	12531271424
r10            0x0	0
r11            0xe8034b138a14010b	-1728455284687109877
r12            0x290183ddc	11007442396
r13            0x2eaefb000	12531511296
r14            0x2aeb00000	11520704512
r15            0x2eaefb000	12531511296
rip            0x28ec519ca	0x28ec519ca <sanitizeStackForVMImpl+33>

---

Since that shared library has the name "javascript" in it, is there a way to completely disable that?

[aadcg]

Unfortunately, the Developer's Manual isn't quite clear about the particular version of WebKit that's needed.

The manual mentions that the latest version should be used for security reasons. Recent WebKit releases had some serious issues (for instance version 2.40.0), but that's the exception rather than the rule. Nyxt version 3.0.0 was tested with WebKit 2.40.1, so you're running the right version.

---

With respect to the javascript library, see the shared objects related to WebKit available on my system below. Notice that you have libjavascriptcoregtk-4.1.so.3.8 but, in my case, it's libjavascriptcoregtk-4.1.so.3.10.

  lrwxrwxrwx 1 root root  29 Jan  1  1970 libjavascriptcoregtk-4.1.so -> libjavascriptcoregtk-4.1.so.0
  lrwxrwxrwx 1 root root  34 Jan  1  1970 libjavascriptcoregtk-4.1.so.0 -> libjavascriptcoregtk-4.1.so.0.3.10
  -r-xr-xr-x 2 root root 29M Jan  1  1970 libjavascriptcoregtk-4.1.so.0.3.10
  lrwxrwxrwx 1 root root  22 Jan  1  1970 libwebkit2gtk-4.1.so -> libwebkit2gtk-4.1.so.0
  lrwxrwxrwx 1 root root  26 Jan  1  1970 libwebkit2gtk-4.1.so.0 -> libwebkit2gtk-4.1.so.0.8.2
  -r-xr-xr-x 2 root root 74M Jan  1  1970 libwebkit2gtk-4.1.so.0.8.2

---

Since that shared library has the name "javascript" in it, is there a way to completely disable that?

Honestly, I don't know. What happens if you delete it or make it inaccessible?

[aartaka]

Since that shared library has the name "javascript" in it, is there a way to completely disable that?

No, that's not possible I believe. At lease WebKit makefile and documentation has no mentions of not building JSCore.

[aadcg]

@baulig we'd really like Nyxt to run on OpenBSD but this is not in our priorities at the moment. Feel free to re-open if we can provide any insight that may help us reach that goal. Thanks.