#5003: test 4038 (ghci) fails on OS X 64 bit.
-------------------------------+--------------------------------------------
    Reporter:  gwright         |       Owner:  gwright      
        Type:  bug             |      Status:  new          
    Priority:  normal          |   Component:  GHCi         
     Version:  7.0.2           |    Keywords:               
    Testcase:                  |   Blockedby:               
          Os:  MacOS X         |    Blocking:               
Architecture:  x86_64 (amd64)  |     Failure:  Runtime crash
-------------------------------+--------------------------------------------

Comment(by altaic):

 In `StgRun` (in `StgCRun.c`), `rsp` gets set to the bogus address just
 before the error. I poked around in `StgRun` a bit and came across a
 correlation. Perhaps it's some sort of mmap bug in `Linker.c`.

 In `./includes/rts/Constants.h`, changing
 {{{
 #define RESERVED_C_STACK_BYTES (2048 * SIZEOF_LONG)
 }}}

 to
 {{{
 #define RESERVED_C_STACK_BYTES (4096 * SIZEOF_LONG)
 }}}

 causes the error to happen twice as soon, i.e.
 {{{
 [...]
 first: 748
 second: 748

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3f8a88
 0x000000010031ab22 in stg_ap_p_info ()
 }}}

 rather than the original
 {{{
 [...]
 first: 501
 second: 501

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3fe8a0
 0x000000010031ac72 in stg_ap_p_info ()
 }}}

 Likewise, changing it to
 {{{
 #define RESERVED_C_STACK_BYTES (1024 * SIZEOF_LONG)
 }}}

 causes the error to happen twice as late, i.e
 {{{
 [...]
 first: 22
 second: 22

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ff6e8
 0x000000010031ab22 in stg_ap_p_info ()
 }}}

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5003#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to