"internal error" in 6-2-branch

Simon P. Jones writes

> There is a known bug in the one-space compacting garbage collector for
> GHC 6.2.1.  It is fixed in the 6.2 branch.
> 
> This bug is shown up by your "space=XXX" choice.  If you omit =
> space=xxx
> you won't use the one-space collector, and the bug will probably vanish.
> I am not sure why you use it.
> [..]
>

Generally,  (Time*Space) cost for a given task  is an important 
quality estimation for the system  instrument + application.

Naturally, the user needs to find out how this parameter evolves from 
version to version. If some task is known to be done within a small 
memory and when it takes large memory in some particular system, then 
this is a serious matter about the system to be investigated. 

Also I use  -M  in order 
(1) to prevent filling all the memory and going to the disk space
(2) to prevent taking much of memory from other users
    ((1),(2) may occur, for example, when ghc has a buggy GC),
(3) to test GHC and Application, because deliberately running task in 
    small memory, and with different -M, often reveals a bug.
    
    Setting different (and small) -M is good for debugging.


> I believe that the bug is already fixed.  To test the 6.2-branch
> compiler (which is what you are trying to do), you need to build the
> stage-2 compiler, else you'll be running a 6.2-branch compiler linked to
> a 6.2.1 run-time system, which has the bug.
>
> If you sat in fptools/ and typed 'make' you should have successfully
> built a stage2 compiler; it lives in ghc/compiler/stage2/ghc-inplace.
> If you use this compiler to compile docon you should be all right.  Or,
> if not, we'd like to know.


Something is wrong here.
We have the pre-installed official 
                          /usr/bin/ghc  6.2.1  -- compiler and ghci.

Then, using  /usr/bin/ghc,  I have built the  6.2-branch  in my home:
  ...
  > cd .../ghcCVS/myfptools
  > ./configure  --prefix=.../ghcCVS/inst
  > make all
  > make install

  > cd myfptools
  > ls ghc/compiler/stage2/
    absCSyn ... ghci ... ghc-6.2.1 ... ghc-inplace 

  > cd ghcCVS/inst
  > ls bin
    ghc ghc-pkg ghci ... ghc-6.2.1 ... ghc-pkg-6.2.1 ghci-6.2.1 
    ...

-- this is the newly installed  ghc-6-2-branch,
this is different from what is in  /usr/bin/ghc
(despite that they write "6.2.1" in the headings),  right? 

I set  $path  too:

    > which ghc 
      /home/mechvel/ghcCVS/inst/bin/ghc
    > which ghci
      /home/mechvel/ghcCVS/inst/bin/ghci

DoCon Makefile  uses $(ghc)  with
                     ghc = /home/mechvel/ghcCVS/inst/bin/ghc

And it compiles differently to  /usr/bin/ghc-6.2.1 official,
I see this because it
* does not seg-fault, takes much smaller memory to build DoCon,
* does not break at compliling Pol3_.hs (in both variants),

ghci  is also different, because it finds the needed instances 
      after   > ghci
              ..> :m DExport
              ..> factor (10 :: Integer)

and 6.2.1 official does not find them.
And still 
    ghc-6.2.1: internal error: scavenge_mark_stack:
                    unimplemented/strange closure type 30 @ 0x41692598

occurs in various situations: in compiling and under ghci,
under -Onot and under -O, and it vanishes in ghci after  > :set +s  

May it occur that with all the above  > ghc -c ...
                                      > ghci ...
use the old run-time support?

Maybe, the `make' should be done twice to erase all trace of old 
6.2.1 ?

I'll ask sysadmin to hide the official 6.2.1 of /usr/bin/
and I'll rebuild ghc-6-2-branch by compiling it by itself, 
and then see. Would it self-make?

Another question: 
as you have docon-2.08-pre, you can reproduce the test with DoCon
under  ghc-6-2-branch,  as I wrote.
For example, `make' DoCon with -O,  `make' T_  with -Onot,
load it and run 
                > ghci $doconpcp T_ +RTS -M..any -RTS
                ...
                > test "log"

And it is supposed to report "internal error ...".
Have you tried this?

-----------------
Serge Mechveliani
mechvel@xxxxxxxx



| Dear GHC developers,
|=20
| I have `made' GHC of   cvs update -r ghc-6-2-branch    (about May 14)
|=20
| by  ghc-6.2.1   on  RedHat Linux (about version 8) libc-2.2, i686.
|=20
| Now, you have the                 docon-2.08-pre
| test, with  Pol3_.hs  containing
|=20
|   instance (LinSolvRing (Pol a), CommutativeRing a) =3D>
|                                           LinSolvRing (UPol (Pol a))
|   ...
|=20
| And      make space=3D-M20m docon
| (-Onot)
| yields
|    ...
|    ...
|     /home/mechvel/docon/2.08/docon/source/export/Pfact3_.hi:
|      openBinaryFile: does not exist (No such file or directory)
|    Compiling Pfact3_
|      ( pol/factor/Pfact3_.hs,
|        /home/mechvel/docon/2.08/docon/source/export/Pfact3_.o )
|
|    No old interface available
|    ghc-6.2.1: internal error: scavenge_mark_stack:
|                    unimplemented/strange closure type 30 @ 0x41692598
|     Please report this as a bug to glasgow-haskell-bugs@xxxxxxxxxxx,
|     or http://www.sourceforge.net/projects/ghc/
|
| Repeating this command, or `making' it from the start under  -M30m
| avoids this report.