Bug 195755
| Summary: | gcc segfaults with malloc_perturb | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dave Jones <davej> |
| Component: | binutils | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | pfrields |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.17.50.0.2-3 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-06-27 12:06:07 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I have found two places where ld used uninitialized memory: http://sourceware.org/ml/binutils/2006-06/msg00283.html but all that it caused to the i386 vsyscall-int80.so was that it couldn't be linked at all, so I'd like to verify this is the same thing as you were seeing and not something else. So, please create a reproducer: 1) note the exact gcc commands to build vsyscall-*.o files as well as vsyscall-*.so 2) add -save-temps to the command lines, attach here the preprocessed vsyscall-*.s files as well as vmlinux.lds you used 3) what exact binutils you were using? 4) what exact MALLOC_PERTURB_=N value was used? Assuming binutils-2.17.50.0.2-3 fixes this, if not, please reopen with details. |
whilst building the kernel on i686, I puzzled as to why as segfaulted when compiling the i386 vsyscall code. as was segfaulting whilst assembling arch/i386/kernel/vsyscall.S in particular, on an incbin of two files.. Looking at the files that were incbin'd explained it.. $ ll arch/i386/kernel/vsyscall-*.so -rwxr-xr-x 1 davej davej 623185380 Jun 17 00:50 arch/i386/kernel/vsyscall-int80.so* -rwxr-xr-x 1 davej davej 623185404 Jun 17 00:50 arch/i386/kernel/vsyscall-sysenter.so* Why were they so enormous ? objdump revealed.. Program Header: LOAD off 0x00000000 vaddr 0xdadadada paddr 0xdadadada align 2**30 filesz 0x25250b3a memsz 0x25250b3a flags r-x DYNAMIC off 0x25250ab6 vaddr 0xffffe590 paddr 0xffffe590 align 2**2 filesz 0x00000078 memsz 0x00000078 flags r-- NOTE off 0x25250986 vaddr 0xffffe460 paddr 0xffffe460 align 2**2 filesz 0x00000018 memsz 0x00000018 flags r-- EH_FRAME off 0x2525099e vaddr 0xffffe478 paddr 0xffffe478 align 2**2 filesz 0x00000024 memsz 0x00000024 flags r-- Normally, without the perturb, it comes out as .. -rwxr-xr-x 1 davej davej 2192 Jun 17 01:38 arch/i386/kernel/vsyscall-int80.so* -rwxr-xr-x 1 davej davej 2216 Jun 17 01:38 arch/i386/kernel/vsyscall-sysenter.so* I tried to put together a small testcase, but there's a bunch of dependant .o's from arch/i386/kernel. Let me know if you can't reproduce, and I'll try again to come up with something small.