Mirror of forum.nim-lang.org

966 :: SIGSEGV when catching exceptions raised by async procs

• l04m33 (orginal) [2015-03-04T12:34:07+01:00] view original

  The problematic code:

  import asyncdispatch, math
  
  randomize()
  
  proc r1() {.async.} =
      echo("r1 going to sleep....")
      await sleepAsync(random(1000) + 500)
      if true:
          raise newException(ValueError, "Oops!")
      echo("r1 is awake.")
  
  proc r2() {.async.} =
      echo("r2 entry")
      try:
          await r1()
      except ValueError:
          echo("r1 raised an exception!!!!")
      echo("r2 return")
  
  waitFor(r2())
  echo("Done.")
  
  # ========= Output =========
  # r2 entry
  # r1 going to sleep....
  # r1 raised an exception!!!!
  # r2 return
  # Traceback (most recent call last)
  # async.nim(20)            async
  # asyncdispatch.nim(1378)  waitFor
  # asyncdispatch.nim(911)   poll
  # asyncdispatch.nim(319)   processTimers
  # asyncdispatch.nim(195)   complete
  # asyncdispatch.nim(1082)  cb
  # SIGSEGV: Illegal storage access. (Try to compile with -d:useSysAssert -d:useGcAssert for details.)
  Run

  I'm using Nim 0.10.2 from the git repo on Linux, and compiled the program with the following command:

  nim c -d:useSysAssert -d:useGcAssert --passC:-g async.nim
  Run

  I peeked around the standard library, but cannot find any similar usage for reference.

  Am I doing anything wrong? Or is this a bug?

---

• Araq (orginal) [2015-03-04T12:53:03+01:00] view original

  Don't use Nim 0.10.2 for async.

---

• dom96 (orginal) [2015-03-04T19:24:07+01:00] view original

  While Araq is correct this bug is also present in 0.10.3. It seems to have something to do with the interaction between exceptions and sleepAsync. I will look into it more when I get a chance.

  Edit: This appears to be segfaulting in excpt.nim. Possibly a Nim bug.

---

• l04m33 (orginal) [2015-03-05T02:22:24+01:00] view original

  Thanks for the info.

  The SIGSEGV vanished just now, when I switched to the devel branch of Nim and tried out rev. d61f326.

  BTW, I'm really shocked when I saw that async procs are implemented using macros. Well done guys.

---