Comment 6 for bug 2009331

I reduced the issue to a simple case that depends on hunchentoot and yason here:

https://github.com/jetmonk/sbcl-web-backtrace-mem-crash

This is likely reproducible on only some SBCL versions (SBCL 2.3.1 on CentOs Linux x64 in my case).

Perhaps the issue is that the backtrace can see method calls with arguments of #<SB-IMPL::STRING-OUTPUT-STREAM {xxxxx}> which have dynamic extent, and are invalid by the time the backtrace sees them. But wouldn't the stack be intact because it is growing after the error, so these streams are still valid, and become invalid only after the stacks moves back past them? As you can tell, my understanding of these issues is not good.

Anyway, if this a real issue, I hope this might provide someone with a way to reproduce it.