Unable to run sample on Linux

[PMunch]

After fixing some minor build issues I was able to build the sample binary, but when I try to run it I just get a crash with:

Traceback (most recent call last)
/tmp/nimCEF/simple.nim(245) simple
/tmp/nimCEF/simple.nim(236) main
/usr/lib/nim/core/macros.nim(567) ncInitialize
SIGSEGV: Illegal storage access. (Attempt to read from nil?)

Any idea what is going on?

[jangko]

ncInitialize contains unsafe pointer arithmetic black magic. probably new version of Nim do different things compared to older version. In the past I also experience crashes on 32 bit OS.

another possibility is binary incompatibility, newer CEF binary might have different proc signature.

[PMunch]

But it is supposed to work by just running nim e build.nims and then ./simple (assuming it can find libcef.so)? I googled the issue and there were some mentions of a certain folder structure it needed to adhere to.

I went back to 0.20.0 and compiled it without modifications just fine, but I still had the same run-time issue.

[jangko]

besides libcef.so there are other files need to be present too. see this

[PMunch]

Yes I found that, but unfortunately it still crashes. According to gdb this is the backtrace of the crash:

#0  0x00007ffff7da9bf4 in __memmove_avx_unaligned_erms () at /usr/lib/libc.so.6
#1  0x00007ffff351cef3 in cef_string_utf16_set () at ./libcef.so
#2  0x00007ffff3474033 in  () at ./libcef.so
#3  0x00007ffff3473f95 in  () at ./libcef.so
#4  0x00007ffff1474450 in cef_initialize () at ./libcef.so
#5  0x0000555555589fb3 in ncInitialize__d1QrZX5eJ9bNLay4RcA0Wgg ()
#6  0x000055555558deab in main__ObKUA7q4DoYU9cLOHHQiOFA ()
#7  0x000055555558eb50 in NimMainModule ()
#8  0x000055555558e047 in NimMainInner ()
#9  0x000055555558e083 in NimMain ()
#10 0x000055555558e0d1 in main ()

And looking at the output of strace I get this:
mmap(NULL, 279830044225536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)

So it appears that somewhere a string is trying to be converted from something that isn't proper string data, and that leads to it trying to allocate a massive amount of memory.

[jangko]

util/nc_util.nim should contains all nim2cef and cef2nim conversion stuff.

[PMunch]

Okay, turns out I was just running it with a CEF version that was way to modern, so the API has changed quite a bit. Using an older version works, but that's obviously not optimal. But looking at the massive diff between the version used by this project and the newest one there is a substantial amount of work to do. Is the thin wrapper automatically generated in any way? Or is it all hand-translated?

[jangko]

they are hand translated. the 'automatic' part handled by macros, but still much manual work.
but if you want to make it run, you only need to translate/modify parts you need.
IIRC only a couple of classes need to be fixed then you can run a simple app.
not all methods and classes need to be fixed.

the complexity came from multi-process and multi-thread nature of the framework.