Mirror of forum.nim-lang.org

5869 :: Nim calling Lemon parser and SIGSEGV

• jdn (orginal) [2020-01-29T23:56:53+01:00] view original

  I'm trying to call a Lemon based parser from Nim. I think Nim is garbage collecting the parsers state but I can't figure out why that is happening. I've created the simplest example of the issue on github. More info on the problem and how to run the code are at the link. There is nothing fancy going here as far as I know as it is just Nim calling into C (the AST is all C code etc.). I'm pretty new to Nim so any input would be greatly appreciated.

---

• Araq (orginal) [2020-01-30T17:14:37+01:00] view original

  I only skimmed it, one thing that stood out is that you don't use .bycopy for your imported structs/objects. I doubt it's the cause of your crashes.

---

• Varriount (orginal) [2020-01-30T17:26:28+01:00] view original

  It appears that (for some reason) the upper 32 bits of the tree pointer in PState.tree are being cleared. You can see this if you add printf("Node at address: %p\n", (void *)e); to the mkNode functions, and then print the value of the tree pointer.

---

• jdn (orginal) [2020-01-31T00:44:51+01:00] view original

  .bycopy. was originally in the pragma for all the C types. I removed any pragma that didn't seem to help to not obfuscate the issue. The code segfaults in dump_ast at the switch statement. The first 32 bits made me think that it was ntype a c integer that was the issue but I don't think so now. Lemon produces a header in this case called calc.h of token types:

  #define ADD                              1
  #define SUB                              2
  #define MUL                              3
  #define DIV                              4
  #define LPAR                             5
  #define RPAR                             6
  #define NUM                              7
  Run

  which the Makefile evokes c2nim to create calc.nim:

  const
    ADD* = 1
    SUB* = 2
    MUL* = 3
    DIV* = 4
    LPAR* = 5
    RPAR* = 6
    NUM* = 7
  Run

  The reason I don't think this is the issue is that I hard coded the c int's to their actual values in both calc.y and main.nim and got the same result.

  Thank you both for your input.

---

• jdn (orginal) [2020-01-31T20:20:37+01:00] view original

  Boy, I haven't been this stumped in a very long time. When run it doesn't seem that the parsers state (PState struct called state) exists for either Nim or C. I've tried a bunch of things and no joy. Anyone on this forum who knows anything about valgrind that could provide any insight as to why the code works when it is evoke and fails when it doesn't? Clearly all my intuition previously was wrong else I'd have this sorted by now. Thanks.

---

• Varriount (orginal) [2020-02-01T12:52:31+01:00] view original

  Hm, have you looked at the generated C code?

---

• jdn (orginal) [2020-02-02T16:26:28+01:00] view original

  Yes, nothing jumped out at me as unusual. Reading the generated C code isn't so clear so I could have missed something. On linux when calc_parser is executing state->tree is 0x0 which shouldn't happen (gdb). When it exits it is no longer null but points to invalid memory and hence the segfault. When running under valgrind it does the same in calc_parser (0x0) but when it exits it points to the correct location and the AST is printed and evaluated. The equivalent with a main.c (all that is really Nim here) works as expected.

---

• jdn (orginal) [2020-02-02T16:30:03+01:00] view original

  ledigbick reported that it works under Windows with a few .cdecl. additions. The current version of the repo should run if you use Windows. Doesn't fix the segfault on Linux. I have a Windows instance in boxes and I'll set up Nim in it a play around but I'm not certain this will help me figure this out.

---

• jdn (orginal) [2020-02-07T23:49:54+01:00] view original

  This problem seems to have been a bug in gcc 8.3.0 (version in debian stable [buster]). Once I tried clang and it worked I installed debian testing on Gnome Boxes and it compiled and ran correctly with gcc 9.2.1.

---