Re: dtc(1): reproducible segmentation fault

[George Abdelmalik]

On Fri, Oct 23, 2015 at 10:40:37AM -0600, Ian Lepore wrote:
> 
> 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
> 

Thanks Ian,

The GPL dtc worked fine. I was actually wanting to compiler the in-tree
zedbaord.dts file. I'd successfully done it some time back in June but must
have been using the GPL dtc without realising it.

George.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: dtc(1): reproducible segmentation fault

[George Abdelmalik]

On Sat, Oct 24, 2015 at 02:11:36PM +0100, David Chisnall wrote:
> On 24 Oct 2015, at 11:07, David Chisnall  wrote:
> > 
> > On 23 Oct 2015, at 17:40, Ian Lepore  wrote:
> >> 
> >> 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.
> > 
> > Please assign the bug to me.
> 
> Actually, it looks as if this is one of the (many) bugs in dtc that I fixed 
> in a bunch of changes that I made (and didn?t get around to committing) last 
> Christmas (https://github.com/davidchisnall/dtc).  Patrick Wildt tested the 
> version that I was working on with a load of things from the GPL dtc test 
> suite and they all passed.  I?m now running a make universe with the new 
> version, and I?ll commit if there are no problems.
> 
> David
> 

Hi David,

You've beaten me to it with the fix before I could lodge the bug report :)

In your repo I've seen that the mmap(2) call now takes the MAP_PRIVATE flag. I
applied that change locally to my source tree and that has fixed the problem.
I've since re-read the mmap(2) man page to find out how that change could
be influential...

 [EINVAL]   None of MAP_ANON, MAP_PRIVATE, MAP_SHARED, or
MAP_STACK was specified.  At least one of these flags
must be included.

Although obvious to me now, I missed it on my previous reads.

Thanks for your assistance. I look forward to your coming set of changes. In
my view DTC is an important tool and I would be willing contribute effort to
making it feature parity with the GPL version if that is lacking.

Keep up the valuable work,
George.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: dtc(1): reproducible segmentation fault

[David Chisnall]

On 25 Oct 2015, at 00:07, George Abdelmalik  wrote:
> 
> You've beaten me to it with the fix before I could lodge the bug report :)
> 
> In your repo I've seen that the mmap(2) call now takes the MAP_PRIVATE flag. I
> applied that change locally to my source tree and that has fixed the problem.
> I've since re-read the mmap(2) man page to find out how that change could
> be influential...
> 
> [EINVAL]   None of MAP_ANON, MAP_PRIVATE, MAP_SHARED, or
>MAP_STACK was specified.  At least one of these flags
>must be included.
> 
> Although obvious to me now, I missed it on my previous reads.
> 
> Thanks for your assistance. I look forward to your coming set of changes. In
> my view DTC is an important tool and I would be willing contribute effort to
> making it feature parity with the GPL version if that is lacking.

It’s now committed (r289935).  Sorry for the delay - I meant to commit the 
changes in January and it slipped down my to-do list.

Please do test with any dts files that you have.  If you find bugs, then please 
report them and assign them to me.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: dtc(1): reproducible segmentation fault

[David Chisnall]

On 23 Oct 2015, at 17:40, Ian Lepore  wrote:
> 
> 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.

Please assign the bug to me.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: dtc(1): reproducible segmentation fault

[David Chisnall]

On 24 Oct 2015, at 11:07, David Chisnall  wrote:
> 
> On 23 Oct 2015, at 17:40, Ian Lepore  wrote:
>> 
>> 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.
> 
> Please assign the bug to me.

Actually, it looks as if this is one of the (many) bugs in dtc that I fixed in 
a bunch of changes that I made (and didn’t get around to committing) last 
Christmas (https://github.com/davidchisnall/dtc).  Patrick Wildt tested the 
version that I was working on with a load of things from the GPL dtc test suite 
and they all passed.  I’m now running a make universe with the new version, and 
I’ll commit if there are no problems.

David

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

dtc(1): reproducible segmentation fault

[George Abdelmalik]

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, ))
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.00,s=0.002578,in=2,out=0 }) = 0 (0x0)
mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 
34384904192 (0x80180)

openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3)
getrusage(0,{ u=0.00,s=0.002697,in=2,out=0 }) = 0 (0x0)
openat(AT_FDCWD,"/usr/src/sys/boot/fdt/dts/arm/zedboard.dts",O_RDONLY,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?

Regards,
George.

--
George Abdelmalik
Director
Principal Software Engineer
Uniridge Pty Ltd
http://www.uniridge.com.au/

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: dtc(1): reproducible segmentation fault

[Garrett Cooper]

> On Oct 23, 2015, at 07:10, George Abdelmalik  
> 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, ))
> 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.00,s=0.002578,in=2,out=0 }) = 0 (0x0)
> mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 
> 34384904192 (0x80180)
> openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3)
> getrusage(0,{ u=0.00,s=0.002697,in=2,out=0 }) = 0 (0x0)
> openat(AT_FDCWD,"/usr/src/sys/boot/fdt/dts/arm/zedboard.dts",O_RDONLY,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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: dtc(1): reproducible segmentation fault

[Ian Lepore]

On Fri, 2015-10-23 at 09:14 -0700, Garrett Cooper wrote:
> > On Oct 23, 2015, at 07:10, George Abdelmalik <
> > gabdelma...@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, ))
> > 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.00,s=0.002578,in=2,out=0 }) = 0 (0x0)
> > mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
> > = 34384904192 (0x80180)
> > openat(AT_FDCWD,"xxx.dtb",O_WRONLY|O_CREAT|O_TRUNC,0666) = 3 (0x3)
> > getrusage(0,{ u=0.00,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

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"