Hi all.
I have a problem profiling the
"hslibs/object-io/Examples/Bounce" example program.
When built with GHC 5.03 CVS (which was in turn
built with 5.02.3) using the default compiler and RTS Makefile settings, the
example runs, but roughly (pauses for GC and slower than the pure Clean
version).
To find the cause I tried building with
profiling turned on:
ghc Main.hs --make -package objectio -prof
-auto-all -o Bounce.exe -lopcodes
When run, the resulting executable crashes with
a requestor in:
__gmpn_divrem_2
divrem_2.c:151
Using an RTS built with the default
debugging options found in "mk/built.mk.sample", I catch the exception with
DrMingw and get the stack dump shown in DEBUGGER OUT ONE (below) - an access
violation in line 3820 of "rts/GC.c"
(get_itbl(frame)->type).
I then inserted a "#undef DEBUG" in
"rts/GC.c".
This just pushes the crash to the next
reference to the same construct - line 3841. See DEBUGGER OUT TWO
- also below. This time there is also a reference to the same gmp
routine as above, which for some reason is not reported in DEBUGGER OUT
ONE.
Any help on interpreting and squishing this one
gratefully accepted.
Cheers
Mike Thomas.
=====================================================
DEBUGGER OUT ONE - DEBUG defined in GC.c
=====================================================
Bounce.exe caused an Access Violation at
location 0056349d in module Bounce.exe Reading from location
0000000d.
Registers:
eax=101c031c ebx=101c0400
ecx=0000000d edx=0000000d esi=101c031c edi=101c23e8
eip=0056349d
esp=0022dd88 ebp=0022ddd0
iopl=0 nv up ei pl zr na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038
gs=0000
efl=00000246
Call stack:
0056349D
Bounce.exe:0056349D threadSqueezeStack
GC.c:3820
...
frame,
prev_frame);
})
> switch (get_itbl(frame)->type)
{
case
UPDATE_FRAME:
upd_frames++;
...
0056378B Bounce.exe:0056378B
threadPaused GC.c:4054
...
{
if (
RtsFlags.GcFlags.squeezeUpdFrames == rtsTrue
)
> threadSqueezeStack(tso);// does black
holing too
else
threadLazyBlackHole(tso);
...
00554592 Bounce.exe:00554592
suspendThread Schedule.c:1532
...
threadPaused(cap->r.rCurrentTSO);
>
cap->r.rCurrentTSO->link = suspended_ccalling_threads;
suspended_ccalling_threads =
cap->r.rCurrentTSO;
...
004795A9
Bounce.exe:004795A9
00A749D0
24448904
=====================================================
DEBUGGER OUT TWO - DEBUG UNdefined in GC.c
=====================================================
Bounce.exe caused an Access Violation at location 00684c7d in module
Bounce.exe Reading from location 00000000.
Registers:
eax=101bf3f4 ebx=006ab3d0 ecx=101bf3d8 edx=11c5d010
esi=006a15fc edi=00000000
eip=00684c7d esp=0022dd98 ebp=0022ddd0
iopl=0 nv up ei ng nz na po
cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038
gs=0000
efl=00000287
Call stack:
00684C7D Bounce.exe:00684C7D
threadSqueezeStack GC.c:3841
...
}
#endif
> if
(get_itbl(frame)->type == UPDATE_FRAME
&&
frame->updatee->header.info == &stg_BLACKHOLE_info)
{
break;
...
00684E8B Bounce.exe:00684E8B threadPaused
GC.c:4054
...
{
if (
RtsFlags.GcFlags.squeezeUpdFrames == rtsTrue
)
> threadSqueezeStack(tso);// does black
holing too
else
threadLazyBlackHole(tso);
...
0066F76A Bounce.exe:0066F76A suspendThread
Schedule.c:1532
...
threadPaused(cap->r.rCurrentTSO);
>
cap->r.rCurrentTSO->link = suspended_ccalling_threads;
suspended_ccalling_threads =
cap->r.rCurrentTSO;
...
0047AEA3 Bounce.exe:0047AEA3
101C0CD8
006AB040
Bounce.exe:006AB040 __gmpn_divrem_2
divrem_2.c:151
...
return
most_significant_q_limb;
> }
...
