From owner-freebsd-current@freebsd.org Fri Oct 23 16:40:44 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B761A1C704 for ; Fri, 23 Oct 2015 16:40:44 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7E3EE21 for ; Fri, 23 Oct 2015 16:40:43 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 23 Oct 2015 16:40:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t9NGebmV021438; Fri, 23 Oct 2015 10:40:37 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1445618437.91534.13.camel@freebsd.org> Subject: Re: dtc(1): reproducible segmentation fault From: Ian Lepore To: Garrett Cooper , George Abdelmalik Cc: freebsd-current@freebsd.org Date: Fri, 23 Oct 2015 10:40:37 -0600 In-Reply-To: References: <562A3FE5.8020809@uniridge.com.au> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 16:40:44 -0000 On Fri, 2015-10-23 at 09:14 -0700, Garrett Cooper wrote: > > On Oct 23, 2015, at 07:10, George Abdelmalik < > > gabdelmalik@uniridge.com.au> wrote: > > > > Hi, > > > > With recent amd64 11.0-current system (as of earlier this week) I > > can reproduciblycw > > get a SIGSEGV when running a command such as > > > > $ dtc -o zb.dtb /usr/src/sys/boot/fdt/dts/arm/zedboard.dts > > Segmentation fault (core dumped) > > > > I've investigated the issue and found that the problem is at line > > 241 of the /usr/src/usr.bin/dtc/input_buffer.cc where the call to > > mmap(2) fails. Snippet below: > > > > 233 mmap_input_buffer::mmap_input_buffer(int fd) : input_buffer(0, > > 0) > > 234 { > > 235 struct stat sb; > > 236 if (fstat(fd, &sb)) > > 237 { > > 238 perror("Failed to stat file"); > > 239 } > > 240 size = sb.st_size; > > 241 buffer = (const char*)mmap(0, size, PROT_READ, > > 242 MAP_PREFAULT_READ, fd, 0); > > 243 if (buffer == 0) > > 244 { > > 245 perror("Failed to mmap file"); > > 246 } > > 247 } > > > > The code incorrectly tests againts 0 instead of MAP_FAILED for > > failure > > which is why the the perror message isn't seen at the terminal, the > > SIGSEGV > > happens later when an attempt to access the buffer array is made. > > > > Also the final parts of truss output are: > > > > .. > > .. > > getrusage(0,{ u=0.000000,s=0.002578,in=2,out=0 }) = 0 (0x0) > > mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) > > = 34384904192 (0x801800000) > > openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3) > > getrusage(0,{ u=0.000000,s=0.002697,in=2,out=0 }) = 0 (0x0) > > openat(AT_FDCWD,"/usr/src/sys/boot/fdt/dts/arm/zedboard.dts",O_RDON > > LY,00) = 4 (0x4) > > fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = > > 0 (0x0) > > fstat(4,{ mode=-rw-r--r-- ,inode=73360,size=5360,blksize=5632 }) = > > 0 (0x0) > > mmap(0x0,5360,PROT_READ,MAP_PREFAULT_READ,4,0x0) ERR#22 'Invalid > > argument' > > close(4) = 0 (0x0) > > SIGNAL 11 (SIGSEGV) > > process killed, signal = 11 (core dumped) > > > > Any help debugging this futher would be much appreciated. I just > > can't understand why > > the mmap in question would fail, and what's invalid about its > > arguments? > > Hi George, > Could you please post the bug report (with your dts file) on > bugs.freebsd.org and CC Ian Lepore and Warner Losh? > Thanks! > -NGie Don't cc me. I looked at the in-tree dtc code once and decided it's too flawed to try to maintain, and it supports only a subset of the full dts syntax. That's why we switched back to using the gnu dtc for buildkernel. But I just discovered that for some reason gnu is not the copy of dtc that gets installed, it's just the one that gets used during a buildkernel. So basically if you do 'dtc -v' and the result is 0.4.0, that's too limited to compile modern dts files, and if the result is 1.4.0 that's the gnu dtc that should work fine, and if it doesn't we probably need to report the problem upstream. -- Ian