summaryrefslogtreecommitdiffstats
path: root/stdlib/except.tl
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2022-06-06 07:07:51 -0700
committerKaz Kylheku <kaz@kylheku.com>2022-06-06 07:07:51 -0700
commit9a57c028f766f57e3774ec6bc18a6b4cb8680fc7 (patch)
tree9a0da003880b76ac01401455f710c4448cb74340 /stdlib/except.tl
parent16305b28e7bd92a6f25610095d626d492020f3ee (diff)
downloadtxr-9a57c028f766f57e3774ec6bc18a6b4cb8680fc7.tar.gz
txr-9a57c028f766f57e3774ec6bc18a6b4cb8680fc7.tar.bz2
txr-9a57c028f766f57e3774ec6bc18a6b4cb8680fc7.zip
string-out-stream: gc issue.
The problem being addressed here showed up for me when compiling with either gcc-7 or gcc-11 on Ubuntu 18, using -fsanitize-undefined. A few test test cases run under --gc-debug were crashing. I narrowed it down to this small test case, whose correct output would be "1": ./txr --gc-debug -p '(sys:fmt-simple 1 : : : :)' "\x6700ACB0缻\x6700ACB0缻 " The issue doesn't have anything to do with -fsanitize-undefined; that just how it got reproduced by chance. I'm reasonably certain that in builds for which "make tests" passes, and the above test case doesn't repro, this issue is absent: the code got generated in such a way that it the string_own call doesn't cause the stream object to be reclaimed. * stream.c (get_string_from_stream): change the order of operations in the ownership transfer of the string from the stream to the returned string object. We capture the string in a local variable, and null out so->buf before calling string_own. The problem is that get_string_from_stream is called in a way where the caller no longer has any use for the stream, and so the object is no longer live. It's possible for the string_own call to cause the stream object to be garbage collected. Therefore, the object must not still be hanging on to the wchar_t * string, which was already transferred to the string object.
Diffstat (limited to 'stdlib/except.tl')
0 files changed, 0 insertions, 0 deletions