#5003: test 4038 (ghci) fails on OS X 64 bit.
---------------------------------+------------------------------------------
Reporter: gwright | Owner: gwright
Type: bug | Status: new
Priority: high | Milestone: 7.2.1
Component: GHCi | Version: 7.0.2
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: x86_64 (amd64) | Failure: Runtime crash
---------------------------------+------------------------------------------
Comment(by gwright):
Replying to [comment:22 simonpj]:
> Great debugging work guys -- thank you for your care and persistence.
>
> 16kbytes per C call does seem a lot!
>
> Does a stack overflow have to lead to a bus error? Couldn't it lead to
"C stack overflow" or something?
>
> Simon
Plain old C just segfaults when you run off the end of the stack. An 8 MB
block is allocated at the top of the virtual address space, and accesses
below (top - 8 MB) are usually to unallocated memory, generating a
segfault. (The .NET framework's fancier runtime that can check the stack
pointer and throw a stack overflow exception.)
It's still strange that the test has sometimes worked, particularly when
compiled rather than interpreted. I'm wondering if in addition to the
stack space there's additional space allocated at high virtual addresses.
Then when we run 4038 we access memory we shouldn't, but since we're not
writing much to the stack, the test (and process) end before the resulting
memory corruption causes a crash.
I'm scratching my head over this one, but I'm happy that this isn't
another OS X linker bug.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5003#comment:24>
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
