From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9936 invoked by alias); 6 Dec 2012 15:19:54 -0000 Received: (qmail 9878 invoked by uid 48); 6 Dec 2012 15:19:34 -0000 From: "howarth at nitro dot med.uc.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/55610] New: cc1 is calling munmap() on part of itself on darwin Date: Thu, 06 Dec 2012 15:19:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: howarth at nitro dot med.uc.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-12/txt/msg00546.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55610 Bug #: 55610 Summary: cc1 is calling munmap() on part of itself on darwin Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: howarth@nitro.med.uc.edu The use of the dragonegg.so plugin with the LLVMPolly.so plugin exposes a flaw where when dyld queries for free memory it is getting a block in the middle of gcc4.7's __DATA segment. The cc1 binary has a 1GB __DATA segment which is huge, but should work, but somehow LLVMPolly.so is being loaded into the middle of the cc1's DATA segment. That causes problems with lazy binding because dyld has a data structure to map from an address to an image. That data structure assumes mach-o images do not overlap. So when dyld is trying to find which image is requesting the lazy binding, it thinks it is cc1 when in fact LLVMPolly.so is requesting the lazy binding. This leads to the binding error. Why does this cc1 have such a huge __DATA segment? Most of the room is in the __bss12 section. Is there some code that calls vm_deallocate on the interior of the __DATA segment? size -l /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 Segment __PAGEZERO: 4294967296 (vmaddr 0x0 fileoff 0) Segment __TEXT: 11014144 (vmaddr 0x100000000 fileoff 0) Section __text: 8725244 (addr 0x100000c80 offset 3200) Section __text_startup: 5 (addr 0x100852f80 offset 8728448) Section __text_cold: 69721 (addr 0x100852f88 offset 8728456) Section __stubs: 984 (addr 0x100863fe2 offset 8798178) Section __stub_helper: 1656 (addr 0x1008643bc offset 8799164) Section __cstring: 573443 (addr 0x100864a38 offset 8800824) Section __const: 534272 (addr 0x1008f0a40 offset 9374272) Section __eh_frame: 1105584 (addr 0x100973140 offset 9908544) total 11010909 Segment __DATA: 1075826688 (vmaddr 0x100a81000 fileoff 11014144) Section __got: 816 (addr 0x100a81000 offset 11014144) Section __nl_symbol_ptr: 16 (addr 0x100a81330 offset 11014960) Section __la_symbol_ptr: 1312 (addr 0x100a81340 offset 11014976) Section __const: 598856 (addr 0x100a81860 offset 11016288) Section __data: 41152 (addr 0x100b13bc0 offset 11615168) Section __static_data: 136 (addr 0x100b1dc80 offset 11656320) Section __pu_bss5: 1202272 (addr 0x100b1dd20 offset 0) Section __bss4: 792 (addr 0x100c43580 offset 0) Section __bss2: 1640 (addr 0x100c43898 offset 0) Section __bss0: 26 (addr 0x100c43f00 offset 0) Section __pu_bss4: 112 (addr 0x100c43f20 offset 0) Section __pu_bss0: 5 (addr 0x100c43f90 offset 0) Section __common: 24 (addr 0x100c43f98 offset 0) Section __pu_bss2: 496 (addr 0x100c43fb0 offset 0) Section __bss12: 1073741824 (addr 0x100c45000 offset 0) Section __bss5: 221067 (addr 0x140c45000 offset 0) Section __bss3: 7632 (addr 0x140c7af90 offset 0) Section __pu_bss3: 1432 (addr 0x140c7cd60 offset 0) total 1075819610 Segment __LINKEDIT: 3719168 (vmaddr 0x140c7e000 fileoff 11661312) For the FSF gcc 4.7.2/dragonegg/LLVMPolly.so combination cc1 is calling munmap() on part of itself which is not legal. If we skip over that munmap, the program runs fine. (gdb) set env DYLD_PRINT_SEGMENTS (gdb) br munmap (gdb) r dyld: Main executable mapped /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 __PAGEZERO at 0x00000000->0x100000000 __TEXT at 0x100000000->0x100A81000 __DATA at 0x100A81000->0x140C7E000 __LINKEDIT at 0x140C7E000->0x14100A000 ... Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc : mov $0x2000049,%eax $17 = 0x14122e000 $18 = 0xd2000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc : mov $0x2000049,%eax $19 = 0x141400000 $20 = 0x2e000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc : mov $0x2000049,%eax $21 = 0x141400000 $22 = 0x400000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc : mov $0x2000049,%eax $23 = 0x142000000 $24 = 0x400000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc : mov $0x2000049,%eax $26 = 0x144ba3000 $27 = 0x5d000 (gdb) c Continuing. Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc : mov $0x2000049,%eax $28 = 0x144d00000 $29 = 0xa3000 (gdb) c Continuing. GNU C (GCC) version 4.7.2 (x86_64-apple-darwin12.2.0) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Versions of loaded plugins: dragonegg: 3.2svn ignoring nonexistent directory +"/sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin12.2.0/4.7.2/../../../../x86_64-apple-darwin12.2.0/include" #include "..." search starts here: #include <...> search starts here: /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin12.2.0/4.7.2/include /usr/local/include /sw/lib/gcc4.7/include /sw/lib/gcc4.7/lib/gcc/x86_64-apple-darwin12.2.0/4.7.2/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C (GCC) version 4.7.2 (x86_64-apple-darwin12.2.0) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.1, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Versions of loaded plugins: dragonegg: 3.2svn Compiler executable checksum: 5da987f9ed3a860be7067d00a0e39a8f Breakpoint 14, 0x00007fff86b94fbc in munmap () 1: x/i $pc 0x7fff86b94fbc : mov $0x2000049,%eax $30 = 0x100c45000 $31 = 0x40000000 (gdb) bt #0 0x00007fff86b94fbc in munmap () #1 0x0000000100808efc in darwin_gt_pch_use_address (addr=Cannot access memory at address 0xffffffff 0x0, sz=, fd=-1, off=0) at +../../gcc-4.7.2/gcc/config/host-darwin.c:60 Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) info shared 0x0000000100808efc 5 cc1 - 0x100000000 exec Y Y +/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 (offset 0x0) Note the address range being unmapped (0x100c45000 - 0x140c45000) which is all in the __DATA segment of cc1: __DATA at 0x100A81000->0x140C7E000 gdb, shows that darwin_gt_pch_use_address is being called with parameters darwin_gt_pch_use_address(NULL, 0, -1, 0); maybe it was a feature in the 32-bit days to free up the space that would have been used by pch if pch was not +active. But for 64-bits there is no shortage of address space. This code also only worked in the past because cc1 did not dlopen() anything. Now that it is, the hole in the +__DATA segment is causing problems. Nick says this goes to Mike Stump to fix it to not unmap.