#15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Description changed by George: Old description:
compiling files in ghci on MacOS eventually results in a panic with error:
{{{ malformed mach-o: load commands size (32800) > 32768 }}}
I can reproduce this problem by repeatedly compiling (and loading) a file and then deleting the .o file. I understand that this an OS limitation but why does repeatedly doing the same thing results in this? i.e. why don't I get it on the first compile (and load). It seems that successive loads are being appended to something eventually resulting in the error.
To duplicate:
ghci -ignore-dot-ghci -fobject-code < ghci.sh >& ghci.out &
If you look for the first "panic" in the .out file you'll see
{{{ Prelude Main> ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib, 5): no suitable image found. Did find: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: malformed mach-o: load commands size (32800) > 32768 /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: stat() failed with errno=25 }}}
The critical part being {{{ malformed mach-o: load commands size (32800) > 32768 }}}
My understanding from https://stackoverflow.com/questions/44902695/too- many-commands-dyld-message-malformed-mach-o-load-commands-size is that this has to do with sizeofcmds but if I understand the output of otool 0l this is only 512 so I don't understand what is causing the errror.
{{{ otool -l c.o|head c.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 1 4 512 0x00002000 }}}
This is irritating but perhaps the priority should be low rather than normal.
New description: compiling files in ghci on MacOS eventually results in a panic with error: {{{ malformed mach-o: load commands size (32800) > 32768 }}} I can reproduce this problem by repeatedly compiling (and loading) a file and then deleting the .o file. I understand that this an OS limitation but why does repeatedly doing the same thing results in this? i.e. why don't I get it on the first compile (and load). It seems that successive loads are being appended to something eventually resulting in the error. To duplicate: ghci -ignore-dot-ghci -fobject-code < ghci.sh >& ghci.out & If you look for the first "panic" in the .out file you'll see {{{ Prelude Main> ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180714 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib, 5): no suitable image found. Did find: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: malformed mach-o: load commands size (32800) > 32768 /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc55569_0/libghc_2084.dylib: stat() failed with errno=25 }}} The critical part being {{{ malformed mach-o: load commands size (32800) > 32768 }}} My understanding from https://stackoverflow.com/questions/44902695/too- many-commands-dyld-message-malformed-mach-o-load-commands-size is that this has to do with sizeofcmds but if I understand the output of otool -l this is only 512 so I don't understand what is causing the errror. {{{ otool -l c.o|head c.o: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedfacf 16777223 3 0x00 1 4 512 0x00002000 }}} This is irritating but perhaps the priority should be low rather than normal. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15446#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler