Skip to content
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

Closed
argiopetech opened this issue Oct 31, 2014 · 4 comments
Closed

Segfault with Data.Text.Lazy.Builder.Int(decimal) #99

argiopetech opened this issue Oct 31, 2014 · 4 comments

Comments

@argiopetech
Copy link

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 as 3 * (fromIntegral (maxBound :: Int) :: Integer); however, it sometimes takes 2-3 evaluations in GHCI to segfault. Conversely, the following fails consistently.

import Data.Text.Lazy.Builder     (toLazyText)
import Data.Text.Lazy.Builder.Int (decimal)

main = print (toLazyText (decimal 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002))

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 or decimal, as simply packing the large decimal value from a string with Data.Text.Lazy.pack and printing it does not cause a problem.

@argiopetech
Copy link
Author

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:

$ cabal exec -- runhaskell -O0 Main.hs 
"2"
Bus error

Whereas without the optimization flag, the output is still consistent, but different:

$ cabal exec -- runhaskell nMain.hs
"Segmentation fault

@argiopetech
Copy link
Author

Some tracing shows this is directly related to a conversion in countDigits.

countDigits v0 = go 1 (fromIntegral v0 :: Word64)

This causes v0 to be truncated to 2, so countDigits returns 1 and vastly undershoots the storage space needed (actually 362 digits-worth).

bos added a commit that referenced this issue Nov 12, 2014
bos added a commit that referenced this issue Nov 12, 2014
@bos bos closed this as completed Nov 12, 2014
@RyanGlScott
Copy link
Member

I believe this also fixes issue #91, so I'll go ahead and close it.

@bos
Copy link
Contributor

bos commented Dec 11, 2014

Thanks, Ryan!

jsonn pushed a commit to jsonn/pkgsrc that referenced this issue Dec 13, 2014
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)
bos added a commit that referenced this issue Feb 18, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants