[nightly] 29-Jun-2005 build of HEAD on OpenBSD/x86
Simon Marlow
simonmar at microsoft.com
Thu Jun 30 04:39:33 EDT 2005
Looking back through the mail archives, these errors started occurring
on 11 March:
http://www.haskell.org//pipermail/cvs-ghc/2005-March/023893.html
And the most likely breaking commit is this one:
http://www.haskell.org//pipermail/cvs-ghc/2005-March/023883.html
What's strange is that this commit has been merged into STABLE, but
you're not seeing any breakage on STABLE.
Cheers,
Simon
On 30 June 2005 04:43, Donald Bruce Stewart wrote:
> Hunting down the ghci failures in head on openbsd:
>
> dons:
>> Build description = HEAD on OpenBSD/x86
>>
>> Unexpected failures:
>> drvrun002(ghci)
>> drvrun003(ghci)
>> drvrun004(ghci)
>> drvrun005(ghci)
>> drvrun006(ghci)
>> drvrun010(ghci)
>> drvrun012(ghci)
>> drvrun014(ghci)
>> drvrun015(ghci)
>
> All these ghci failures get triggered when -no-recomp is on. With
> -no-recomp,
> we segfault (!) at runtime, sometimes after getting a bit of the
> output done.
>
> manzano$ '/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/
> stage2/ghc-inplace' -dcore-lint -Di386_unknown_openbsd
> drvrun002.hs --interactive -v0 -no-recomp
> <drvrun002.genscript ===== program output begins here
> ===== program output begins here
> Options {s = SpecialOptions {test = 42}}
> zsh: segmentation fault (core dumped)
>
>
'/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage2/ghc-inpla
ce'
>
> Turning off -no-recomp, it all runs fine:
>
> manzano$ '/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/
> stage2/ghc-inplace' -dcore-lint -Di386_unknown_openbsd
> drvrun002.hs --interactive -v0 <drvrun002.genscript
> ===== program output begins here
> ===== program output begins here
> Options {s = SpecialOptions {test = 42}}
> Options {s = SpecialOptions {test = 42}}
>
> Ok, so somehow recompilation checking is leading helping an rts crash.
> Cranking up gdb:
>
> manzano$ gdb -c ghc-6.5.core
>
>
>
>
>
>
>
> /home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage2/ghc-6.5
> GNU gdb 6.1 ... Core was generated by `ghc-6.5'. Program terminated
> with signal 11, Segmentation fault. ... #0 0x1c9dd456 in
> stg_ap_0_info ()
>
> Hmm. Same issue for drvrun002..drvrun015.
>
>> arr015(ghci)
>
> Looks like this test tiggers it too. Runs fine without -no-recomp.
>
> manzano$ '/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/
> stage2/ghc-inplace' -dcore-lint -Di386_unknown_openbsd
> arr015.hs --interactive -v0 -no-recomp < arr015.genscript
> check_tc DataziTuple.Z2T{(w) tc 46}
> ===== program output begins here
> ===== program output begins here
> zsh: segmentation fault (core dumped)
>
>
'/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage2/ghc-inpla
ce'
>
> #0 0x1c9dd456 in stg_ap_0_info ()
>
>> TH_reifyType2(normal)
>> TH_genEx(normal)
>
> Failing on linux too, unrelated.
>
>> arrowrun001(ghci)
>
> -no-recomp again.
>
>> fed001(ghci)
>
> Without -no-recomp:
> manzano$ '/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/
> stage2/ghc-inplace' -dcore-lint -Di386_unknown_openbsd
> fed001.hs --interactive -v0 -fglasgow-exts <fed001.genscript
> ===== program output begins here
> ===== program output begins here
> fed001: fed001.o: unknown symbol `Main_d1XH'
> fed001: internal error: ASSERTION FAILED: file Linker.c, line 1281
>
> Please report this as a bug to
> glasgow-haskell-bugs at haskell.org, or
> http://www.sourceforge.net/projects/ghc/
>
> With -no-recomp:
> manzano$ '/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/
> stage2/ghc-inplace' -dcore-lint -Di386_unknown_openbsd
> fed001.hs --interactive -v0 -fglasgow-exts -no-recomp
> <fed001.genscript
>
> fed001.hs:8:0: Warning: foreign declaration uses deprecated
> non-standard syntax fed001.hs:12:0: Warning: foreign declaration
> uses deprecated non-standard syntax ===== program output begins
> here ===== program output begins here
> zsh: segmentation fault (core dumped)
>
>
'/home/dons/head-gcc3/i386-unknown-openbsd/ghc/compiler/stage2/ghc-inpla
ce'
>
> gdb says:
> #0 0x1c9e73fb in interpretBCO (cap=0x3c139cc0) at
> Interpreter.c:1196 1196 marshall_fn (
> (void*)(cap->r.rCurrentTSO->sp + ret_dyn_size) ); (gdb) where
> #0 0x1c9e73fb in interpretBCO (cap=0x3c139cc0) at
> Interpreter.c:1196 #1 0x1c9d80ca in schedule
> (mainThread=0x3c13a0a0, initialCapability=0x3c139cc0) at
> Schedule.c:696 #2 0x1c9d8eec in waitThread_ (m=0x3c13a0a0,
> initialCapability=0x3c139cc0) at Schedule.c:2720 #3
> 0x1c9d8e03 in scheduleWaitThread (tso=0x517e000, ret=0x0,
> initialCapability=0x3c139cc0) at Schedule.c:2606 #4 0x1c9d4828
> in rts_evalLazyIO (p=0x3c0d6408, ret=0x0) at RtsAPI.c:459 #5
> 0x1c9d3499 in main (argc=9, argv=0xcfbf1a2c) at Main.c:110
>
> Ah! Now we have something that sounds sensible.
>
>> ffi003(ghci)
>
> -no-recomp again. Sames gdb result as for fed001.
>
>> ffi004(ghci)
>> ffi006(ghci)
>> ffi007(ghci)
>> ffi008(ghci)
>> ffi009(ghci)
>> ffi010(ghci)
>> ffi011(ghci)
>> ffi012(ghci)
>> ffi013(ghci)
>
> All as for fed001.
>
>> cg015(ghci)
>> cg035(ghci)
>
> -no-recomp again. Same gdb as for fed001.
>
>> cg055(ghci)
>> cg056(ghci)
>
> -no-recomp As for drvrun tests.
>
>> conc038(threaded)
>
> Seems like some other issue.
>
> newThread started
> - mainThread
> - Haskell: 2
> newThread back again
> 1 sec later
>
> shutting down
> --- 1,6 ----
> newThread started
> newThread back again
> + mainThread
> 1 sec later
>
> shutting down
>
>> conc039(threaded)
>
> Some other issue again:
>
> $ ./conc039
> conc039: performGC_: interrupted
>
>> conc049(ghci)
>
> -no-recomp, same as fed001.
>
> Also on linux.
>
>> genUpTo(ghci)
>
> -no-recomp, as for drvrun*.
>
>> simpl008(normal)
>> xmlish(ghci)
>> hlist(ghci)
>> hopat(ghci)
>> perm(ghci)
>> ioref001(ghci)
>> text001(ghci)
>> tup001(ghci)
>> stableptr001(ghci)
>> joao-circular(prof)
>> joao-circular(profasm)
>> joao-circular(ghci)
>> andy_cherry(ghci)
>> galois_raytrace(ghci)
>> seward-space-leak(ghci)
>> ghci008(ghci)
>> ghci011(ghci)
>> ghci012(ghci)
>> ghci001(ghci)
>
> Didn't look at these.
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc
More information about the Cvs-ghc
mailing list