-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Segfault with Data.Text.Lazy.Builder.Int(decimal) #99
Comments
This appears only to be an issue when compiling without optimization. Compiling with any optimization level causes output as expected, while compiling without an optimization flag or interpreting seems to cause issues. Amusingly, testing this seems to have stumbled on another consistent failure. With the code from above in a sandbox with only Text-1.2.0.0 installed, the following occurs:
Whereas without the optimization flag, the output is still consistent, but different:
|
Some tracing shows this is directly related to a conversion in
This causes |
I believe this also fixes issue #91, so I'll go ahead and close it. |
Thanks, Ryan! |
changelog: 1.2.0.2 * Bumped lower bound on deepseq to 1.4 for compatibility with the upcoming GHC 7.10 1.2.0.1 * Fixed a buffer overflow in rendering of large Integers (haskell/text#99)
I'm seeing segfaults when using
decimal
with large numbers, particularly in interpreted code. I first noticed the problem under GHC 7.8.2, and it persists with GHC 7.8.3. Text version is 1.2.0.0.The attached should segfault without output if compiled and run, and segfault after some small quantity of output if interpreted (I've seen just
"
, as well as"2"
). . I have had similar failures with numbers as small as3 * (fromIntegral (maxBound :: Int) :: Integer)
; however, it sometimes takes 2-3 evaluations in GHCI to segfault. Conversely, the following fails consistently.This is possibly a compiler issue, as I've received 'internal error: stg_ap_p_ret' from GHCI while playing with it. I haven't been able to reproduce that, so I'm bouncing it here first.
This seems to be in
toLazyText
ordecimal
, as simply packing the large decimal value from a string withData.Text.Lazy.pack
and printing it does not cause a problem.The text was updated successfully, but these errors were encountered: