#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):
I've now seen the bug in the compiled 4038.hs. It's much easier to see
what's going in this case.
What's happening is that we're simply blowing past the end of our
process's C stack. I can see this in `gdb`. I've set a breakpoint at
`stg_makeStablePtrzh`, since this is the function in which the memory
error occurs in the compiled code. When the breakpoint is first
encountered, the `$rsp` (the C stack pointer) is at `0x7fff5fbfb530`.
When the crash occurs, `$rsp` is pointing to `0x7fff5f3ffa70`:
{{{
gwright-macbook> gdb
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC
2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-apple-darwin".
(gdb) source gdbinit
(gdb) file ./4038
Reading symbols for shared libraries ... done
Reading symbols from /Users/gwright/tmp/ghc-HEAD/ghc/4038...done.
(gdb) break stg_makeStablePtrzh
Breakpoint 1 at 0x100344f78
(gdb) run
Starting program: /Users/gwright/tmp/ghc-HEAD/ghc/4038
Reading symbols for shared libraries ++. done
Breakpoint 1, 0x0000000100344f78 in stg_makeStablePtrzh ()
(gdb) info reg
rax 0x100054cb0 4295314608
rbx 0x100b041a1 4306518433
rcx 0x1 1
rdx 0x1003c82f8 4298932984
rsi 0x100b00140 4306501952
rdi 0x228 552
rbp 0x100b05310 0x100b05310
rsp 0x7fff5fbfb530 0x7fff5fbfb530
r8 0x0 0
r9 0x19 25
r10 0x100b05628 4306523688
r11 0x100b05610 4306523664
r12 0x100b041a8 4306518440
r13 0x1003c9558 4298937688
r14 0x100b04169 4306518377
r15 0x100b050c0 4306522304
rip 0x100344f78 0x100344f78 <stg_makeStablePtrzh>
eflags 0x203 515
cs 0x27 39
ss 0x0 0
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) ignore 1 506
Will ignore next 506 crossings of breakpoint 1.
(gdb) c
Continuing.
Breakpoint 1, 0x0000000100344f78 in stg_makeStablePtrzh ()
(gdb) info reg
rax 0x10018e7c8 4296599496
rbx 0x10038d421 4298691617
rcx 0x10038d230 4298691120
rdx 0x100b249a0 4306651552
rsi 0x100b24931 4306651441
rdi 0x100346e10 4298403344
rbp 0x100b21340 0x100b21340
rsp 0x7fff5f3ffa70 0x7fff5f3ffa70
r8 0x1009fc0a0 4305436832
r9 0x1009fc0a4 4305436836
r10 0x1 1
r11 0x10038d421 4298691617
r12 0x100b24998 4306651544
r13 0x1003c9558 4298937688
r14 0x10038d421 4298691617
r15 0x100b210c0 4306636992
rip 0x100344f78 0x100344f78 <stg_makeStablePtrzh>
eflags 0x213 531
cs 0x27 39
ss 0x0 0
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) c
Continuing.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ffa68
0x0000000100344fab in stg_makeStablePtrzh ()
(gdb) info reg
rax 0x0 0
rbx 0x10038d421 4298691617
rcx 0x1003d3ad0 4298980048
rdx 0x100b249a0 4306651552
rsi 0x100b24931 4306651441
rdi 0x10038d421 4298691617
rbp 0x100b21340 0x100b21340
rsp 0x7fff5f3ffa70 0x7fff5f3ffa70
r8 0x1009fc0a0 4305436832
r9 0x1009fc0a4 4305436836
r10 0x1 1
r11 0x10038d421 4298691617
r12 0x100b24998 4306651544
r13 0x1003c9558 4298937688
r14 0x10038d421 4298691617
r15 0x100b210c0 4306636992
rip 0x100344fab 0x100344fab <stg_makeStablePtrzh+51>
eflags 0x10287 66183
cs 0x27 39
ss 0x0 0
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000100344f78 <stg_makeStablePtrzh>
breakpoint already hit 508 times
(gdb)
}}}
The difference in `$rsp` between the first breakpoint and the crash is
8370880 (decimal). 8 megabytes is 8388608, just a bit bigger. Check the
process limits:
{{{
gwright-macbook> ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 2560
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 266
virtual memory (kbytes, -v) unlimited
}}}
The C stack is 8 megabytes, and we're simply running off the end.
The question now is what is pushing without popping?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5003#comment:13>
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
