From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17147 invoked by alias); 26 Apr 2015 16:14:09 -0000 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 Received: (qmail 17125 invoked by uid 48); 26 Apr 2015 16:14:06 -0000 From: "hdusel at macbay dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/65895] New: Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49)) Date: Sun, 26 Apr 2015 16:14: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-Version: 5.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: minor X-Bugzilla-Who: hdusel at macbay dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone cf_gcchost cf_gcctarget cf_gccbuild Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg02225.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65895 Bug ID: 65895 Summary: Segfault building cross GCC 5.1.0 for Target AVR on Mac OSX 10.10.3 (using Apple LLVM version 6.1.0 (clang-602.0.49)) Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hdusel at macbay dot de Target Milestone: --- Host: Mac OS X 10.10.3 Target: AVR Build: Mac OS X 10.10.3 Using Apple LLVM version 6.1.0 (clang-602.0.49) to build released version 5.1.0 leads into a segfault: ----------------------------------- g++ /tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/config/avr/gen-avr-mmcu-specs.c -o gen-avr-mmcu-specs -I. -I. -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/. -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../include -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libcpp/include -I/tmp/build_cross_gcc/gcc-5.1.0_build_avr/./gmp -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gmp -I/tmp/build_cross_gcc/gcc-5.1.0_build_avr/./mpfr -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/mpfr -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/mpc/src -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libdecnumber -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libdecnumber/dpd -I../libdecnumber -I/tmp/build_cross_gcc/gcc-5.1.0_arch/gcc-5.1.0/gcc/../libbacktrace clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated rm -rf device-specs mkdir device-specs && cd device-specs && ../gen-avr-mmcu-specs /bin/sh: line 1: 62583 Segmentation fault: 11 ../gen-avr-mmcu-specs make[2]: *** [s-device-specs] Error 139 make[1]: *** [all-gcc] Error 2 make: *** [all] Error 2 ----------------------------------- I finally found the reason for the segfault! It is located within gcc/config/avr/gen-avr-mmcu-specs.c In the function print_mcu(const avr_mcu_t *mcu) For every spec file that is about to be generated by gen-avr-mmcu-specs a file handle is created but this handle is __not__ closed when the function leaves. On OS X 10.10.3 (haven't tried other versions of Mac OS X) the total number of opened files per process is apparently lower than the files processed by this tool. Hence after this count of opened handles has exceeded the OS will return NULL for any further attempt to open a new file. -> So accessing a NULL Pointer for the file handler leads to the segfault. The solution is simple: Simply call fclose(f) when the function leaves. In addition it would be fine if a returning file handle of NULL will be checked and acknowledged by the tool by an appropriate error message either. At least the code should not attempt to proceed with a NULL for the file handle though. I verified this proposed changes on my system -> build proceeds.