Mirror of forum.nim-lang.org

9910 :: SIGSEGV when creating a dunamic library in Nim and use it in nim (and posiibbly in other places too)

• teras (orginal) [2023-02-19T20:11:13+01:00] view original

  I am trying to create a library in Nim, which ideally could be used in all languages that support C-style libraries, including Nim itself. But it fails, probably beacuse of my Nim inexperience :(

  First what I have succeed so far.

  First the library

  proc lalein*(format:cstring): int {.dynlib, exportc, cdecl.} =
    echo "in proc"
    format.len
  Run

  compiled with nim c -d:release -d:strip -d:VERSION=0.1 --opt:size -d:lto --noMain:on --app:lib -o:./target/liblalein.linux.so lalein

  And how to use it:

  proc lalein(format:cstring): int {.importc, stdcall, dynlib: "./../target/liblalein.linux.so".}
  echo "start"
  echo lalein("test123")
  Run

  and compile it as nim c -d:VERSION=0.1 --opt:size -d:lto -o:./target/laleintest.linux laleintest

  When run, I correctly get the result "7" as the length of the string.

  But now, when I change the library to

  proc lalein*(format:cstring): int {.dynlib, exportc, cdecl.} =
    echo "in proc"
    echo $format
    format.len
  Run

  I get this error:

  
  start
  in proc
  Traceback (most recent call last)
  /usr/src/app/laleintest.nim(3) laleintest
  SIGSEGV: Illegal storage access. (Attempt to read from nil?)
  fish: Job 1, './target/laleintest.linux 123465' terminated by signal SIGSEGV (Address boundary error)
  Run

  It would be OK for me, if not even len was correct, but I don't understand why len works, but reading the string itself it doesn't.

---

• enthus1ast (orginal) [2023-02-19T20:15:21+01:00] view original

  i would compile both with --gc:arc and maybe even -d:useMalloc then see if it still crashes.

---

• teras (orginal) [2023-02-19T21:56:54+01:00] view original

  I used --gc:arc and it works!

  I am a bit confused though, what about memory management. Let's change a bit the library function to

  proc lalein*(format:cstring): cstring {.dynlib, exportc, cdecl.} =
    "<" & $format & ">"`
  Run

  This, with arc works! But what happened with the resulting cstring? And even more, if the call wasn't by nim, but by a C application, isn't this a memory leak? And how should be handled?

  I'll try to write now a C program that will use it and check. I am more interested what is the "proper" and "correct" way to handle this.

  Thanks again.

---

• teras (orginal) [2023-02-19T22:51:00+01:00] view original

  I used dlopen & dlsym to use the shared Nim procedure.

  Everything still works as expected.

  But I am still curious about what should be the preferred way not to have a memory leak.

---

• PMunch (orginal) [2023-02-19T23:15:55+01:00] view original

  This has cropped up a bit lately, so I decided to write a bit of a longer response: https://peterme.net/dynamic-libraries-in-nim.html

  Hopefully that should at least cover the basics. I guess I might add a section about loading libraries in the future. But right now it's time for bed.

---

• teras (orginal) [2023-02-20T00:14:59+01:00] view original

  Thank you for the reply. Indeed I saw the other post but still my answers weren't answered and I preferred to start a new post.

  Thank you for honoring us with your answers!

  you might need to manually allocate and free some memory, or create destructors :

  My preference would have been to use destructors, since providing a "buffer" could be either "not enough". To be safe usually you need to call the method twice, which is a waste of cycles for me. Destructors might be a bit "dangerous" (in terms that the user won't free up the resource), but is more straight forward.

---

• PMunch (orginal) [2023-02-20T13:13:03+01:00] view original

  When I said destructors I meant Nim destructors. This is essentially a procedure you can attach to a type which will then be called when the GC needs to free the resources. Doing this you can create a wrapper around a C library which manages memory automatically on the Nim side of things.

---

• sls1005 (orginal) [2023-02-20T16:57:39+01:00] view original

  I think that SIGSEGV was because you didn't call the .so 's NimMain, so you don't have a GC set up for the shared library, and Nim didn't know to setup one. For Nim it's just a C library. But $ requires GC. It can explain why it works with ARC, because setting up the GC is not required for ARC.

---

• teras (orginal) [2023-02-22T13:47:16+01:00] view original

  Thank you for the insights. Now it's much more clear. Indeed there doesn't seem to have a memory leak. I tried to call the method millions of times, while watching memory, and there's no leak.

  I also tried to use GC_ref on a cstring, or even string, but this wasn't considered as a reference, but I wrapped it inside a ref object and then I could. When I did that, and make sure that GC_ref is balanced by another GC_unref, everything worked.

---