SIGSEGV exiting nested try/except when using walkDir iterator

[gradha]

The example at https://gist.github.com/gradha/5408302 runs without problems when whisky = false. However, when whisky = true the output is:

Doing retry
We love crashing!
Traceback (most recent call last)
weird.nim(29)            weird
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Error: execution of an external program failed

I expected it to keep walking. It is fun that the problem is the walkDir iterator, actually the last try/except block doesn't need to call removeFile, just having it echo a string is enough for the example to crash.

[gradha]

The test https://gist.github.com/gradha/5408365 where the for/iterator is moved to a separate proc doesn't crash.

[gradha]

Still doesn't work on master or devel. Want a PR for a new create tests/compile/twalker2.nim and close this issue?

[dom96]

Better to keep it open and to add the test once it's fixed IMO.

[skyfex]

Doesn't seem to crash with -d:release

[skyfex]

Think I managed to boil it down to a minimal example:

proc test() =
  raise newException(EOS, "Problem")

try:
  test()
except EOS:
  for y in [1]:
    discard
  try:
    discard
  except EOS:
    discard
echo "Test passed"

[skyfex]

So the for loop in the above example seems to be the root of the issue. If you replace it with nothing (or an if-block or just a block: or something like it), it works.

Nimrod generates a "popCurrentException" when it exits the loop, which sets currentexception to null, then when exiting the "except" block, there's another "popCurrentException" which now tries to access "currentexception" which is nil.

[skyfex]

A different test that fails for the same reason:

proc test() =
  raise newException(EOS, "Problem")

try:
  test()
except EOS:
  for y in [1, 2, 3]:
    discard
  for y in [1, 2, 3]:
    discard
echo "Test passed"

[skyfex]

So it's actually break that does it:

try:
  raise newException(EOS, "Problem")
except EOS:
  block:
    break

[skyfex]

Mystery solved.. the "break" statement tries to clean up the exception because it thinks it's going to exit the exception handling block. This code illustrates when it does this correctly:

block:
  try:
    raise newException(EOS, "Problem")
  except EOS:
    break