Opened 2 years ago

Last modified 2 years ago

#12756 new bug

ghci gives stg_ap_v_ret error

Reported by: ryanreich Owned by:
Priority: normal Milestone:
Component: GHCi Version: 8.0.1
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


The following interaction with ghci occurs:

Prelude> :l Test.hs
[1 of 2] Compiling BigWord          ( lib/BigWord.hs, interpreted )
[2 of 2] Compiling Main             ( Test.hs, interpreted )
Ok, modules loaded: BigWord, Main.
*Main> main
<interactive>: internal error: stg_ap_v_ret
    (GHC version 8.0.1 for x86_64_unknown_linux)
    Please report this as a GHC bug:
Aborted (core dumped)

whereas the compiled file Test.hs executes without error. See the attached files.

Attachments (2)

Test.hs (50 bytes) - added by ryanreich 2 years ago.
Minimal main function
BigWord.hs (4.2 KB) - added by ryanreich 2 years ago.
Source library

Download all attachments as: .zip

Change History (5)

Changed 2 years ago by ryanreich

Attachment: Test.hs added

Minimal main function

Changed 2 years ago by ryanreich

Attachment: BigWord.hs added

Source library

comment:1 Changed 2 years ago by AlexET

After a bit of reducing I think there is a bug in the code meaning the unsafeRead/unsafeWrite in addBigWords are out of bounds. This is because although we have arrays we use have bounds (1,1) and we write at index 1, unsafeRead and unsafeWrite always use 0-indexed array indexes rather than using the array bounds (because they are meant to be fast and unsafe). The OOB write means that any thing can happen. In the case of compiled we happen to ignore it, when interpreted we happen to crash.

comment:2 Changed 2 years ago by ryanreich

You are totally right. That was very careless on my part. So is this an "incorrect" bug report, despite the exhortation from ghci, or should the error be caught better?

comment:3 Changed 2 years ago by simonpj

Writing out of bounds with unsafeWrite is surely a library error, no? Can't we just fix it?

Amaxing work to figure out what it was -- thank you AlexET!

Note: See TracTickets for help on using tickets.