Skip site navigation (1)Skip section navigation (2)
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>