Date: Fri, 23 Oct 2015 10:40:37 -0600 From: Ian Lepore <ian@freebsd.org> To: Garrett Cooper <yaneurabeya@gmail.com>, George Abdelmalik <gabdelmalik@uniridge.com.au> Cc: freebsd-current@freebsd.org Subject: Re: dtc(1): reproducible segmentation fault Message-ID: <1445618437.91534.13.camel@freebsd.org> In-Reply-To: <F6FF4D7B-C380-4410-8A4D-6E376DF76C7D@gmail.com> References: <562A3FE5.8020809@uniridge.com.au> <F6FF4D7B-C380-4410-8A4D-6E376DF76C7D@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1445618437.91534.13.camel>