GHC 5.03 CVS NT2000 Mingw32 - Possible profiling problem in rts/GC.c (or in gmp?)

[Mike Thomas]

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;
> }
 
 ...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20020618/317c5df1/attachment.htm