Mirror of forum.nim-lang.org

9767 :: Default orc crash simple jester httpbeast

• niminuse001 (orginal) [2022-12-27T17:09:39+01:00] view original

  Hello:

  Built nim on linux amd64 and tried simple jester route cited on jester page. Got this:

  INFO Jester is making jokes at http://0.0.0.0:5000 Starting 2 threads Listening on port 5000 No stack traceback available SIGSEGV: Illegal storage access. (Attempt to read from nil?) Segmentation fault (core dumped)

  When I switch to -mm:refc or --mm:markandsweep it works ok.

  Is this known?

---

• niminuse001 (orginal) [2022-12-27T17:12:40+01:00] view original

  This is the better results from the example on jester page.

  INFO Jester is making jokes at http://0.0.0.0:5000 Starting 2 threads Listening on port 5000 Traceback (most recent call last)

  /home/wmusicjr/.nimble/pkgs2/httpbeast-0.4.1-b23e57a401057dcb9b7fae1fb8279a6a2ce1d0b8/httpbeast.nim(83) eventLoop

  /home/wmusicjr/nim/lib/system/orc.nim(46) nimIncRefCyclic

  SIGSEGV: Illegal storage access. (Attempt to read from nil?) Segmentation fault (core dumped)

---

• niminuse001 (orginal) [2022-12-27T17:16:10+01:00] view original

  The basic jester app produced second result:

  example.nim

  import htmlgen import jester

  routes:

  get "/":

  resp h1("Hello world")

---

• niminuse001 (orginal) [2022-12-27T17:19:57+01:00] view original

  More info. I have developed a web crud web service with jester and prologue both of which work fine with getting data under stress with refc and markandsweep. Jester fails right away as above. Prologue runs for indeterminate time and then segv's. The stress is just running GETs on small datamodel with 3 simulated uses slight delays as random and random loop count.

---

• niminuse001 (orginal) [2022-12-27T17:22:38+01:00] view original

  System is older debian linux.

  Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

---

• niminuse001 (orginal) [2022-12-27T17:54:06+01:00] view original

  And BTW, the failures are happening with orc.

---

• Cnerd (orginal) [2022-12-27T19:48:06+01:00] view original

  The crash is not because of orc. It's from trying to access a ref or pointer object that is nil. The problem is probably in your database code. You can tell the os to avoid the error by importing std / segfault in the file causing the segfault error

---

• Cnerd (orginal) [2022-12-27T19:48:55+01:00] view original

  Also you can try using the not nil pragma to make sure that your procedures do not return a nil value

---

• niminuse001 (orginal) [2022-12-27T20:10:02+01:00] view original

  But there isn't any DB code in the crash of the simple jester example. Cited in the 2nd example above and on the jester github page.

  It's just a hello world route.

  In the larger services I've written the crashes are in the same place in org suggest in the segv message and originates in httpbeast.

---

• niminuse001 (orginal) [2022-12-27T20:10:54+01:00] view original

  It orignates in httpbeast both in jester using it externally and from what I understand prologue is using an older version cloned from time past.

---

• niminuse001 (orginal) [2022-12-27T20:37:30+01:00] view original

  This the line I was referring to saying no check on incoming ptr p. It's the first line.

  let h = head(p) inc h.rc, rcIncrement

---

• Araq (orginal) [2022-12-27T20:42:35+01:00] view original

  Report bugs on github please.

---

• niminuse001 (orginal) [2022-12-27T21:05:39+01:00] view original

  Thanks Araq. When Microsoft (owners of github) finally make me a job offer after all the rejections since 1992 I'll stop boycotting an account on github. :)

  I don't think I can file a bug therefore. I encourage you to do as I really want to see Nim surge.

---

• niminuse001 (orginal) [2022-12-27T21:08:49+01:00] view original

  and I do apologize for using this forum to report this but it's been around since orc became default and I really wanted to get it to someone. This was my best effort.

  I'll take your personal email though. I'm at: wmcontact@protonmail.com

---

• Araq (orginal) [2022-12-27T21:23:37+01:00] view original

  Fair enough. Can't blame anybody for avoiding Microsoft.

---

• niminuse001 (orginal) [2022-12-27T21:27:13+01:00] view original

  Glad you understand.

  I hope help nim take a step.

---

• dyu (orginal) [2022-12-28T17:49:59+01:00] view original

  Fair enough. Can't blame anybody for avoiding Microsoft.

  Part of the reason why I like nim's BDFL :-)

---

• arik (orginal) [2022-12-29T02:14:15+01:00] view original

  Howdy, I got the same exact error. I used the flags for orc, release, and threads on. It worked when I ran it outside of VS Code and outside of zellij, with a simple fish console. I don't know why that fixed it, but it worked for me.

---

• arik (orginal) [2022-12-29T02:27:18+01:00] view original

  Ok nevermind that last post I made. It seems like the executable needs some time after it builds to host the server. It seems like a timing issue, it kept displaying that same error until I gave it a second, and spammed ./SampleServer until it stopped showing that error and eventually worked. Although, if you stop the server and try running it again, you will get the same issue, and you have to spam ./SampleServer until it starts to work again with no issue.

---