Ticket #1437 (closed bug: worksforme)

Opened 6 years ago

Last modified 5 years ago

Build failures on Mac OS X 10.5

Reported by: maeder@… Owned by:
Priority: normal Milestone: 6.8.2
Component: Compiler Version: 6.6.1
Keywords: Cc: dgoldsmith@…, Christian.Maeder@…
Operating System: MacOS X Architecture: x86
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

Deborah (goldsmit _at_ apple.com) wrote:

OK, I redid it:

1. Recreate source distribution from tar.bz2 downloads in new directory
2. Move in mk/build.mk to work around splitter incompatibility with Leopard
3. ./configure
3. make

It still crashes in the same place:

../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name  base-2.1.1 -O -Rghc-timing -fgenerics  -fgenerics    -c GHC/Float.lhs -o GHC/Float.o  -ohi GHC/Float.hi
make[2]: *** [GHC/Float.o] Segmentation fault

in the same way:

Process:         ghc-6.6.1 [3655]
Path:            /Volumes/Totoro/source/ghc-6.6.1/compiler/stage1/ghc-6.6.1
Identifier:      ghc-6.6.1
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  make [3457]

Date/Time:       2007-05-22 15:54:06.011 -0700
OS Version:      Mac OS X 10.5 (9A446)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000
Crashed Thread:  0

Thread 0 Crashed:
0   ghc-6.6.1                           0x00750f7f sbqE_info + 15

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00750f70  ebx: 0x008da008  ecx: 0x00000002  edx: 0xffffc002
  edi: 0x01148b40  esi: 0x01148b38  ebp: 0x0264e924  esp: 0xbfffd4e0
   ss: 0x0000001f  efl: 0x00010216  eip: 0x00750f7f   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x004aff64

Binary Images:
    0x1000 -   0x83cff3 +ghc-6.6.1 ??? (???) <86ce72f02577fae2f8266dc0239744af> /Volumes/Totoro/source/ghc-6.6.1/compiler/stage1/ghc
-6.6.1
  0xe69000 -   0xeaefff +GMP ??? (???) /Library/Frameworks/GMP.framework/Versions/A/GMP
0x8fe00000 - 0x8fe2bff8  dyld 84.0 (???) <b289815b39c9e37e061530b97617d5f3> /usr/lib/dyld
0x9049f000 - 0x904a6fed  libgcc_s.1.dylib ??? (???) <62f15ce2792a1b8cd6505ccf778e6cab> /usr/lib/libgcc_s.1.dylib
0x910ac000 - 0x911f2fe8  libSystem.B.dylib ??? (???) <1a04d9c7751575fb6fdd1f292f33a405> /usr/lib/libSystem.B.dylib
0x95953000 - 0x95955fe7  libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib

Change History

Changed 6 years ago by dgoldsmith@…

On the latest Leopard build, the splitter incompatibility is still gone, but the crash is still there.

Changed 6 years ago by guest

Sorry, that should be "the splitter incompatibility is gone."

Changed 6 years ago by dgoldsmith@…

  • cc dgoldsmith@… added

I can reproduce the crash using gdb. Here is some debugging output:

(gdb) run -B/Volumes/Totoro/source/ghc-6.6.1 -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase?.h -funbox-strict-fields -package-name base-2.1.1 -O -Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Float.lhs -o GHC/Float.o -ohi GHC/Float.hiStarting program: /Volumes/Totoro/source/ghc-6.6.1/compiler/stage1/ghc-6.6.1 -B/Volumes/Totoro/source/ghc-6.6.1 -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase?.h -funbox-strict-fields -package-name base-2.1.1 -O -Rghc-timing -fgenerics -fgenerics -split-objs -c GHC/Float.lhs -o GHC/Float.o -ohi GHC/Float.hi Reading symbols for shared libraries +.+. done

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x00000000 0x00750f7f in sbqE_info () (gdb) disassem Dump of assembler code for function sbqE_info: 0x00750f70 <sbqE_info+0>: movsd 0x4(%esi),%xmm0 0x00750f75 <sbqE_info+5>: movsd %xmm0,(%esp) 0x00750f7a <sbqE_info+10>: movsd (%esp),%xmm0 0x00750f7f <sbqE_info+15>: xorpd 0x83cf98,%xmm0 0x00750f87 <sbqE_info+23>: movsd %xmm0,0x8(%esp) 0x00750f8d <sbqE_info+29>: movsd 0x8(%esp),%xmm0 0x00750f93 <sbqE_info+35>: movsd %xmm0,0x38(%ebx) 0x00750f98 <sbqE_info+40>: add $0x4,%ebp 0x00750f9b <sbqE_info+43>: jmp *0x0(%ebp) 0x00750f9e <sbqE_info+46>: nop 0x00750f9f <sbqE_info+47>: nop 0x00750fa0 <sbqE_info+48>: add %al,(%eax) 0x00750fa2 <sbqE_info+50>: add %al,(%eax) 0x00750fa4 <sbqE_info+52>: add %al,(%eax) 0x00750fa6 <sbqE_info+54>: add %al,(%eax) 0x00750fa8 <sbqE_info+56>: enter $0x17f1,$0x0 0x00750fac <sbqE_info+60>: inc %edx 0x00750fad <sbqE_info+61>: add %al,(%eax) 0x00750faf <sbqE_info+63>: add %ah,(%ebx) 0x00750fb1 <sbqE_info+65>: add %al,(%ecx) 0x00750fb3 <sbqE_info+67>: add %cl,0x45c70075(%ecx) End of assembler dump. (gdb) info registers eax 0x750f70 7671664 ecx 0x2 2 edx 0xffffc002 -16382 ebx 0x8da008 9281544 esp 0xbfffd4f0 0xbfffd4f0 ebp 0x24b9924 0x24b9924 esi 0x1167a68 18250344 edi 0x1167a70 18250352 eip 0x750f7f 0x750f7f <sbqE_info+15> eflags 0x10216 66070 cs 0x17 23 ss 0x1f 31 ds 0x1f 31 es 0x1f 31 fs 0x0 0 gs 0x37 55

Changed 6 years ago by guest

Sorry about the formatting. Here is the same information again, hopefully formatter better this time:
(gdb) disassem
Dump of assembler code for function sbqE_info:
0x00750f70 <sbqE_info+0>:       movsd  0x4(%esi),%xmm0
0x00750f75 <sbqE_info+5>:       movsd  %xmm0,(%esp)
0x00750f7a <sbqE_info+10>:      movsd  (%esp),%xmm0
0x00750f7f <sbqE_info+15>:      xorpd  0x83cf98,%xmm0
0x00750f87 <sbqE_info+23>:      movsd  %xmm0,0x8(%esp)
0x00750f8d <sbqE_info+29>:      movsd  0x8(%esp),%xmm0
0x00750f93 <sbqE_info+35>:      movsd  %xmm0,0x38(%ebx)
0x00750f98 <sbqE_info+40>:      add    $0x4,%ebp
0x00750f9b <sbqE_info+43>:      jmp    *0x0(%ebp)
0x00750f9e <sbqE_info+46>:      nop    
0x00750f9f <sbqE_info+47>:      nop    
0x00750fa0 <sbqE_info+48>:      add    %al,(%eax)
0x00750fa2 <sbqE_info+50>:      add    %al,(%eax)
0x00750fa4 <sbqE_info+52>:      add    %al,(%eax)
0x00750fa6 <sbqE_info+54>:      add    %al,(%eax)
0x00750fa8 <sbqE_info+56>:      enter  $0x17f1,$0x0
0x00750fac <sbqE_info+60>:      inc    %edx
0x00750fad <sbqE_info+61>:      add    %al,(%eax)
0x00750faf <sbqE_info+63>:      add    %ah,(%ebx)
0x00750fb1 <sbqE_info+65>:      add    %al,(%ecx)
0x00750fb3 <sbqE_info+67>:      add    %cl,0x45c70075(%ecx)
(gdb) info registers
eax            0x750f70 7671664
ecx            0x2      2
edx            0xffffc002       -16382
ebx            0x8da008 9281544
esp            0xbfffd4f0       0xbfffd4f0
ebp            0x24b9924        0x24b9924
esi            0x1167a68        18250344
edi            0x1167a70        18250352
eip            0x750f7f 0x750f7f <sbqE_info+15>
eflags         0x10216  66070
cs             0x17     23
ss             0x1f     31
ds             0x1f     31
es             0x1f     31
fs             0x0      0
gs             0x37     55

Changed 6 years ago by maeder@…

I don't think that "sbqE" has something to do with the ghc sources so we need to contact the apple developers of OS X 10.5

Changed 6 years ago by igloo

GHC generates random names like sbqE_info when compiling.

Changed 6 years ago by maeder@…

This means that we have to keep the C-files (adding -keep-hc-files to GhcStage1HcOpts in mk/build.mk) when building the stage1 compiler. My grep showed:

fgrep sbqE_info */*/*/*
Binary file compiler/stage1/iface/TcIface.o matches
Binary file compiler/stage1/rename/RnExpr.o matches
Binary file compiler/stage1/typecheck/TcRnDriver.o matches

Changed 6 years ago by maeder@…

Maybe it is worth testing if the above line:

../../compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase.h -funbox-strict-fields -package-name  base-2.1.1 -O -Rghc-timing -fgenerics  -fgenerics    -c GHC/Float.lhs -o GHC/Float.o  -ohi GHC/Float.hi

also fails if ../../compiler/ghc-inplace is replaced with the installed ghc.

Changed 6 years ago by dgoldsmith@…

I built with -keep-hc-files, but could not figure out which of the three files with sbqE_info was the one involved in the crash. I tried disassembling the .o files containing sbqE_info, but none of them contains the code that is crashing. The code that is crashing is in the binary of the compiler (of course), but I can't figure out which .o file it came from.

Changed 6 years ago by guest

Running the command line:

ghc -H16m -O -fglasgow-exts -cpp -Iinclude -"#include" HsBase?.h -funbox-strict-fields -package-name base-2.1.1 -O -Rghc-timing -fgenerics -fgenerics -c GHC/Float.lhs -o GHC/Float.o -ohi GHC/Float.hi

instead of using the built stage1 compiler succeeds, so the problem is definitely that the built stage1 compiler has something wrong with it.

Changed 6 years ago by maeder@…

I've forgotten, that compiling with -O0 does not go via C, so -keep-hc-files must be given with -fvia-C (or did you find any *.hc sources that contained sbqE_info). The alternative would be to -keep-s-file and -fasm, but I rather look at C-code than at assembly.

Changed 6 years ago by maeder@…

sbqE_info also matches in the installed ghc-6.6.1/lib/ghc-6.6.1/libHSbase.a. So it may only get in via linking?

Changed 6 years ago by maeder@…

I've set -keep-hc-files under GhcLibHcOpts += in mk/build.mk and found:

libraries/base/GHC/Float.hc:static StgWord sbqE_info[] = {
libraries/base/GHC/Float.hc:II_(sbqE_info);
libraries/base/GHC/Float.hc:Sp[2] = (W_)&sbqE_info;

I'm not sure if the name sbqE_info is created deterministically, though. (I'll try to prepare hc-sources.)

Changed 6 years ago by guest

I've verified that the installed libHSbase.a contains code that looks like the code that is crashing.

Changed 6 years ago by maeder@…

As described under  http://hackage.haskell.org/trac/ghc/wiki/Building/Porting I've created a hc-file-bundle at  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/ghc-6.6.1-i386-apple-darwin-hc.tar.gz

Making the bundle reported the following (hopefully unimportant) errors:

tar: ghc-6.6.1/rts/AutoApply_debug.hc: Cannot stat: No such file or directory
tar: ghc-6.6.1/rts/AutoApply_thr.hc: Cannot stat: No such file or directory
tar: ghc-6.6.1/rts/AutoApply_thr_debug.hc: Cannot stat: No such file or directory
tar: ghc-6.6.1/rts/AutoApply_thr_p.hc: Cannot stat: No such file or directory
tar: ghc-6.6.1/libraries/haskell-src/Language/Haskell/Parser.hs: Cannot stat: No
such file or directory

Indeed I my files had names like AutoApply_debug.debug_hc, AutoApply_thr.thr_hc, etc.

When trying to boot from these files I got the following error:

Apply.hc:104: warning: no previous prototype for 'stg_PAP_entry'
Apply.hc:152: warning: no previous prototype for 'stg_AP_entry'
Apply.hc:187: warning: no previous prototype for 'stg_AP_STACK_entry'
../driver/mangler/ghc-asm Apply.raw_s Apply.s
Darwin/x86: -fPIC -via-C doesn't work yet, use -fasm. Aborting. at ../driver/mangler/ghc-asm line 877, <INASM> line 268.
gmake: *** [Apply.s] Error 255
gmake: *** Deleting file `Apply.s'
rm Apply.raw_s

And I don't know how to continue

Changed 6 years ago by maeder@…

When I try to build a distribution with the following mk/build.mk

BIN_DIST=1
Project=Ghc
SRC_HC_OPTS     = -O -fasm -keep-s-files -keep-raw-s-files
GhcStage1HcOpts = -O -fasm -keep-s-files -keep-raw-s-files
GhcStage2HcOpts = -O -fasm -keep-s-files -keep-raw-s-files
GhcLibHcOpts    = -O -fasm -keep-s-files -keep-raw-s-files

Making fails with:

make -C compiler stage=2
../compiler/stage1/ghc-inplace -O -fasm -keep-s-files -keep-raw-s-files  -istage
2/utils  -istage2/basicTypes  -istage2/types  -istage2/hsSyn  -istage2/prelude
-istage2/rename  -istage2/typecheck  -istage2/deSugar  -istage2/coreSyn  -istage
2/specialise  -istage2/simplCore  -istage2/stranal  -istage2/stgSyn  -istage2/si
mplStg  -istage2/codeGen  -istage2/main  -istage2/profiling  -istage2/parser  -i
stage2/cprAnalysis  -istage2/ndpFlatten  -istage2/iface  -istage2/cmm  -istage2/
nativeGen  -istage2/ghci -Istage2 -DGHCI -DBREAKPOINT -package template-haskell
-threaded -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package u
nix -package Cabal -package regex-compat -ignore-package lang -recomp -Rghc-timi
ng -O -fasm -keep-s-files -keep-raw-s-files -H16M '-#include "cutils.h"' -packag
e-name  ghc-6.6.1   -fgenerics    -c basicTypes/OccName.lhs-boot -o stage2/basic
Types/OccName.o-boot  -ohi stage2/basicTypes/OccName.hi-boot

basicTypes/OccName.lhs-boot:1:0:
    Failed to load interface for `Prelude':
      Use -v to see a list of the files searched for.
<<ghc: 18007308 bytes, 4 GCs, 97412/97412 avg/max bytes residency (1 samples), 1
6M in use, 0.00 INIT (0.00 elapsed), 0.02 MUT (0.06 elapsed), 0.01 GC (0.02 elap
sed) :ghc>>
make[2]: *** [stage2/basicTypes/OccName.o-boot] Error 1
make[1]: *** [stage2] Error 2
make: *** [bootstrap2] Error 2

What goes wrong here? It works if GhcLibHcOpts is not set (it then starts compiling the library with the stage1 compiler)

Changed 6 years ago by maeder@…

I made a new binary distribution on our Mac OS X 10.4. Could you check if this build makes any difference?  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/asm-ghc-6.6.1-i386-apple-darwin.tar.bz2

The mk/build.mk I've used was:

BIN_DIST=1
Project=Ghc
SplitObjs=NO
SRC_HC_OPTS     = -O -fasm -keep-s-files -keep-raw-s-files
GhcStage1HcOpts = -O -fasm -keep-s-files -keep-raw-s-files
GhcStage2HcOpts = -O -fasm -keep-s-files -keep-raw-s-files

If this still fails, we could inspect the *.s sources or I can try to make another distribution with some debugging flags switched on

Changed 6 years ago by maeder@…

Changed 6 years ago by guest

  • cc Christian.Maeder@… added

Changed 6 years ago by dgoldsmith@…

I tried using the binary distribution Christian supplied, and it still dies with a segmentation fault compiling Float.lhs during the bootstrap.

Changed 6 years ago by Christian.Maeder@…

This odd symbol sbqE_info turns up in my GHC/Float.s and .raw_s files (as well as in Data/Sequence.*.)

I had to recompile everything with GhcLibWays = in mk/build.mk because the libraries's .s and .raw_s files had been overwritten by the profiling "lib-way".

I've packed my whole tree under  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/asm-ghc-6.6.1-Mac-OS-10.4.tar.bz2

Maybe the *.o files can be removed and somehow recreated form the *.s files (My top-level directory was /Users/Shared/maeder/bug/)

Trying to add -DDEBUG to SRC_HC_OPTS failed immediately with:

/home/mac-bkb/bin/ghc -M -optdep-f -optdep.depend  -osuf o -optdep--exclude-module=System.Directory.Internals   -O -fasm -DDEBUG -keep-s-files -keep-raw-s-files -I. -Iinclude -Rghc-timing -O -fasm -keep-s-files -keep-raw-s-files -ignore-package Cabal -I../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Compat/Unicode.hs Distribution/Compat/FilePath.hs Distribution/Compat/ReadP.hs Distribution/Compiler.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Version.hs Language/Haskell/Extension.hs

../libraries/Cabal/Distribution/Compiler.hs:63:7:
    Could not find module `HUnit':
      Use -v to see a list of the files searched for.
<<ghc: 33769752 bytes, 3 GCs, 125816/125816 avg/max bytes residency (1 samples), 289M in use, 0.00 INIT (0.00 elapsed), 0.05 MUT (0.41 elapsed), 0.01 GC (0.02 elapsed) :ghc>>
make[1]: *** [depend] Error 1
make: *** [stage1] Error 1

I suppose the module name should be Test.Unit

Changed 6 years ago by Christian.Maeder@…

I've somehow managed to build a binary dist with -DDEBUG. Deborah, could you please try if it makes any difference? (It has no profiling libs but extra-libs, because Cabal needed HUnit)  http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/versions/debug-ghc-6.6.1-i386-apple-darwin.tar.bz2

Changed 6 years ago by guest

This particular problem appears to be gone with ghc-6.8.1 and 10.5 GM.

Changed 6 years ago by chak

  • status changed from new to closed
  • resolution set to worksforme

I agree with the previous poster that the problem does not appear to be present in 6.8.1 and the HEAD. Hence, I close this ticket.

Changed 5 years ago by igloo

  • milestone changed from 6.8 branch to 6.8.2
Note: See TracTickets for help on using tickets.