Mirror of forum.nim-lang.org

6094 :: SIGSEGV: Illegal storage access.

• mantielero (orginal) [2020-03-21T11:03:31+01:00] view original

  This is the second time I face this error:

  SIGSEGV: Illegal storage access. (Attempt to read from nil?)

  So I am pretty sure this is something that I systematically do wrong. This happens when I wrap some libraries.

  My question is what is the right strategy to debug this sort of problem (bearing in mind I have never used gdb). Any particular recommended read?

---

• Araq (orginal) [2020-03-22T07:51:26+01:00] view original

  When you wrap C code, use c2nim.

  Use .cdecl as the calling convention, .bycopy for object/struct wrapping.

  Use cint instead of int and in general the right types, especially types of the right size for binary compatibility.

  On Linux/OSX you can run your program through valgrind to see where the bug really happens and not just when it caused a crash (that's an important difference).

---

• mantielero (orginal) [2020-03-22T15:36:32+01:00] view original

  (Just for the record; I haven't checked if these are already known issues or if they are actually issues or my misuse)

  I am playing again with c2nim. I am not sure if this could be a problem:

  typedef enum VSColorFamily {
      cmGray   = 1000000,
      cmRGB    = 2000000
  } VSColorFamily;
  
  typedef enum VSPresetFormat {
      pfNone = 0,
      pfGray8 = cmGray + 10,
      ....
  Run

  gets converted into:

  type
    VSColorFamily* {.size: sizeof(cint).} = enum
      cmGray = 1000000, cmRGB = 2000000
    
    VSPresetFormat* {.size: sizeof(cint).} = enum
      pfNone = 0, pfGray8 = cmGray + 10,   ...
  Run

  Shouldn't it be?

  pfGray8 =  cmGray.int + 10
  Run

  given that cmGray's type is VSColorFamily.

  Additionally, it looks like the ordering of the items is not correct. For example, if you have:

  pfGray8 = cmGray + 10,
      pfGray16,
      
      pfGrayH,
      pfGrayS,
      
      pfYUV420P8 = cmYUV + 10,
  Run

  it seems like c2nim is not taking into account if pfYUV420P8`is smaller than `pfGray8, because of their values.

  The same occurs with the ordering of chars. Nim complains due to the following ordering:

  type
     enum
       ptFunction = 'm',
       ptInt = 'i'
  Run

  Additionally, it looks like:

  typedef struct VSMap VSMap;
  Run

  does not get converted into:

  type
     VSMap*  {.bycopy.} = object
  Run

  Finally, just to check, from:

  (const VSAPI *) getVapourSynthAPI(int version);
  Run

  I had:

  proc getVapourSynthAPI*(version:cint):ptr VSAPI    {.importc,dynlib: libName.}
  Run

  while c2nim produces:

  cast[ptr VSAPI](getVapourSynthAPI(int, version))
  Run

---

• mantielero (orginal) [2020-03-22T16:29:15+01:00] view original

  Thanks @Araq, that helped me fix the bug.

---