|
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; > } ... |
- Re: GHC 5.03 CVS NT2000 Mingw32 - Possible profiling pr... Mike Thomas
- Re: GHC 5.03 CVS NT2000 Mingw32 - Possible profili... Mike Thomas
- RE: GHC 5.03 CVS NT2000 Mingw32 - Possible profili... Simon Peyton-Jones
