Mirror of forum.nim-lang.org

4356 :: Hitting a SIGSEGV in the garbage collector

• vsajip (orginal) [2018-11-05T17:38:02+01:00] view original

  I'm trying to port a library and hitting a problem in the GC. I'm not sure I can reduce it to a small program which exhibits the problem. The key bits are:

  
  $ nim --version
  Nim Compiler Version 0.19.0 [Linux: amd64]
  Compiled at 2018-09-26
  Copyright (c) 2006-2018 by Andreas Rumpf
  
  git hash: f6c5c636bb1a1f4e1301ae0ba5a8afecef439132
  active boot switches: -d:release
  
  $ nimble test
  ...
  Traceback (most recent call last)
  test1.nim(31)            test1
  config.nim(448)          failingProc
  gc.nim(493)              newObjRC1
  gc.nim(185)              decRef
  SIGSEGV: Illegal storage access. (Attempt to read from nil?)
  Run

  The lines in config.nim in failingProc where it happens are

  
  447    var s = $text
  448    result.text = s
  Run

  and these lines have been executed many times through successive calls to failingProc from the test. The text variable is initialised at the top of failingProc using

  
    var text : seq[Rune] = @[]
  Run

  and the intervening lines just add some runes to it before the failing line. If I add various echo lines, the location of the failure above the GC call moves around (e.g. to system.nim(216)). There's nothing special about N where it fails on the N th call to failingProc - with extra echo lines, it fails at a different time during processing with those lines in gc.nim.

  Any ideas on how best to debug this type of situation? Are there known issues with GC on 0.19.0 which have been fixed since it was released?

---

• Araq (orginal) [2018-11-05T18:58:21+01:00] view original

  • We need a real test case, reduced or not.
  • We also need to know your CPU/OS combination.
  • We need to know which of the --gc:boehm|refc|markAndSweep GCs produce the problem.

  Any ideas on how best to debug this type of situation?

  Try Nim's different GC options.

  Are there known issues with GC on 0.19.0 which have been fixed since it was released?

  The GCs have no known issues that would produce the behaviour you're describing.

---

• vsajip (orginal) [2018-11-05T21:03:14+01:00] view original

  Well, it's probably something I'm doing. It fails on both Ubuntu Linux 16.04 and Windows 10 (both amd-64). I'll do some more digging before expecting anyone else to spend time looking at it. Are there any settings one can use to e.g. find "shouldn't happen" memory overwrite problems, short of running with Valgrind or similar? Failure occurred with various of the GCs, so I have to take another look at my code.

---

• mratsim (orginal) [2018-11-05T22:17:05+01:00] view original

  Are you using raw pointers or multithreading somewhere?

  Are you calling a C library perhaps?

---

• vsajip (orginal) [2018-11-06T11:09:25+01:00] view original

  No, it's all pure Nim, so one shouldn't be able to shoot oneself in the foot :-(

---