Segmentation fault on `for` list comprehension at certain size

[avitkauskas]

commit 45d7de06e5e14c54572dafb9ea44e10e0a6da22e on Mac OS 14.6.1 Apple M1, memory 8G.

The following code gives segmentation fault at size 137953 and higer:

(def size 137953) 
(for [a (range size)] 1)

With 2 bindings it segfaults at size 97 and higer:

(def size 97) 
(for [a (range size) 
      b (range size)]
  1)

With 3 bindings it segfauts at size 21 and higer:

(def size 21) 
(for [a (range size) 
      b (range size)
      c (range size)]
  1)

[quoll]

Also on a Mac: MBP, MacOS 15.0, Apple M3 Max, memory 36G. Configured/compiled with env:

CPLUS_INCLUDE_PATH=/opt/homebrew/include
LDFLAGS=/opt/homebrew/lib/libcrypto.a
SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk

The first test did not fail for me until 138017. The second and third tests both segfault.

Interestingly, I had a typo while testing 138017. The following sequence at a new repl does work for me:

(def size 13801)
(def size 138017)
(for [a (range size)] 1)

[avitkauskas]

This will be related to chunking of the sequences. These for loops work until certain number of 32-element-size chunks and then segfaults on the next chunk boundary.

[jeaye]

Thanks for taking the time to report this!

This will be related to chunking of the sequences. These for loops work until certain number of 32-element-size chunks and then segfaults on the next chunk boundary.

I think this is an accurate assessment. I have some changes I'm planning to make to jank's sequences which will alleviate most of the common crashes by simplifying the API. I'll leave this open until that is fixed.

Compared to figuring out AOT compilation, getting a REPL server going, getting release binaries for everyone, etc. this is low priority for me. However, this is something which I will fix, when it makes sense, since I recognize it's a blocker issue.