The problem reproduced here occurs when an exception is thrown from user code and reaches clojure.main code responsible for exception reporting. Due to the use of pprint, reporting code can fail, obscuring the error and printing a rather unexpected Java stack trace, which is probably most obscure in case of StackOverflow.
The root cause is potentially buggy ex-info (ex-data with values having broken pprint methods or reference cycles, like overtone/at-at#20) being passed to Throwable->map
in clojure.main/report-error. Throwable->map
itself calls ex-data
in a couple of places.
The "less simple" of the attached patches replaces :clojure.main/trace
(the result of Throwable->map
) in the report, however an even more advanced one would be able to replace ex-data everywhere in :clojure.main/trace
where it can occur.
Being able to narrow down which part of the report caused pprint to fail is an open problem - I haven't looked much into clojure.pprint
itself.
In the patch drafts, I haven't considered the intricacies of reporting errors reporting errors - I think a Java stack trace should be enough, otherwise what if we get another nasty ex-data when reporting an error reporting an error reporting an error?
I also haven't checked if it's possible to break pprint for things other than ex-data keys/values - maybe exceptions or even stack frames themselves? Those cases though should be less common.
I was basing on the master branch Clojure, commit 5451cee0 when preparing and testing patch drafts.