Re: [Toybox] [landley/toybox] toybox ps give out a segment fault (#74)

[Rob Landley]

On 08/31/2017 03:11 PM, Elliott Hughes wrote:
> another instance today from automated testing:

Ok, I pushed an attempted fix.

The delay was that I wanted to create a test harness that spawns and
exits a lot of processes while ps or top repeatedly run, and try to
trigger the conditions of the failure (I.E. see the bug myself and then
maybe leave something running overnight to make sure it stays up), but
the _theory_ of what's happening is pretty clear so I can plug one more
hole in the meantime anyway.

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] musl intentionally broke chrt

[enh]

On Thu, Aug 31, 2017 at 1:46 PM, Rob Landley  wrote:
> On 08/30/2017 10:25 AM, enh wrote:
>> no: the point of the C library is to hide the mapping from
>> functionality to system call. if you ever do port to BSD/macOS you'll
>> need to cope with their syscall differences if you don't let the C
>> library do it, and you're likely to hit places on Android where the
>> traditional system call isn't allowed because bionic doesn't use it
>> and seccomp disables the rest.
>
> Indeed. A broken C library was doing this, then stopped.
>
> On the one hand, this is a musl bug. (He disagrees with the system call
> Linux implemented, so he broke his wrapper to punish people who try to
> use it. If he didn't provide any wrapper I could probe at compile time,
> but musl provides broken stuff you can only tell is broken at runtime,
> so a build that supports cross compiling has no choice but to either
> bloat the code with runtine workarounds, stop supporting musl, or have
> config switches to manually select the behavior at compile time.)
>
> On the other hand, I remember gcc and glibc pointing fingers at each
> other for over FIVE YEARS about -gc-sections breaking stdout flushing at
> exit. The busybox maintainer I handed off to did a presentation
> explaining the problem in in 2010. Doesn't seem to be on youtube but if
> you can dig up code old enough to play "ogg" format (remember that?) the
> pdf and video are at:
>
>   http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf
>
> http://free-electrons.com/pub/video/2010/elc/elc2010-vlasenko-dead-code.ogv
>
> (Fascinating problem, and really annoying to those of trying to just use
> the darn toolchain to built working code...)
>
> Rich is never going to admit he's wrong on this, or on the nommu fork()
> issue, or the meta-mistake of musl not having a #define so we can
> reliably work around his design mistakes ourselves. Me refusing to add a
> workaround for his design decisions reduces to the same "gcc and glibc
> devs pointing fingers at each other and each refusing to change" problem
> that sucks for end users.
>
> In this instance, chrt isn't core functionality, so I can punt for a
> while. But there will be a 4th instance of this, it's only matter of time...
>
>>> Right now I've thrown it back on the todo list, which means "musl stays
>>> broken" is the default for now. Probably acceptable. Lemme finish this
>>> utf8 plumbing and then I need to fix ps again, then get back to... was
>>> lsof or dd next?
>>
>> didn't you get in to utf8 because of my wc -m patch? :-)
>
> Working on it. It's one of those "I'd like to do what I consider the
> _proper_ fix" things that's honestly been a bit of a luxury these days.
>
> I wrote a for loop to go from 0 to UINT_MAX, and I'm comparing the
> mbrtowc(, str, 4, ) results to my contextless utf8towc(, str,
> len) output, and I'm fixing every deviation between the two. I'm
> currently trying to figure out why 0xeda080 _isn't_ 0xd800. (glibc
> translates wc 0xd800 as f8a08a83 but it's less than  so
> https://en.wikipedia.org/wiki/UTF-8 says it should be 3 bytes and I'm
> CONFUSED...)

U+d800 is a surrogate, so shouldn't be valid in utf8.

> (Context-related edge cases aside, I want utf8 support enabled
> regardless of locale and the glibc performance of its multibyte code is
> _terrible_, so this is worth doing anyway.)
>
> Rob



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] musl intentionally broke chrt

[Rob Landley]

On 08/30/2017 10:25 AM, enh wrote:
> no: the point of the C library is to hide the mapping from
> functionality to system call. if you ever do port to BSD/macOS you'll
> need to cope with their syscall differences if you don't let the C
> library do it, and you're likely to hit places on Android where the
> traditional system call isn't allowed because bionic doesn't use it
> and seccomp disables the rest.

Indeed. A broken C library was doing this, then stopped.

On the one hand, this is a musl bug. (He disagrees with the system call
Linux implemented, so he broke his wrapper to punish people who try to
use it. If he didn't provide any wrapper I could probe at compile time,
but musl provides broken stuff you can only tell is broken at runtime,
so a build that supports cross compiling has no choice but to either
bloat the code with runtine workarounds, stop supporting musl, or have
config switches to manually select the behavior at compile time.)

On the other hand, I remember gcc and glibc pointing fingers at each
other for over FIVE YEARS about -gc-sections breaking stdout flushing at
exit. The busybox maintainer I handed off to did a presentation
explaining the problem in in 2010. Doesn't seem to be on youtube but if
you can dig up code old enough to play "ogg" format (remember that?) the
pdf and video are at:

  http://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf

http://free-electrons.com/pub/video/2010/elc/elc2010-vlasenko-dead-code.ogv

(Fascinating problem, and really annoying to those of trying to just use
the darn toolchain to built working code...)

Rich is never going to admit he's wrong on this, or on the nommu fork()
issue, or the meta-mistake of musl not having a #define so we can
reliably work around his design mistakes ourselves. Me refusing to add a
workaround for his design decisions reduces to the same "gcc and glibc
devs pointing fingers at each other and each refusing to change" problem
that sucks for end users.

In this instance, chrt isn't core functionality, so I can punt for a
while. But there will be a 4th instance of this, it's only matter of time...

>> Right now I've thrown it back on the todo list, which means "musl stays
>> broken" is the default for now. Probably acceptable. Lemme finish this
>> utf8 plumbing and then I need to fix ps again, then get back to... was
>> lsof or dd next?
> 
> didn't you get in to utf8 because of my wc -m patch? :-)

Working on it. It's one of those "I'd like to do what I consider the
_proper_ fix" things that's honestly been a bit of a luxury these days.

I wrote a for loop to go from 0 to UINT_MAX, and I'm comparing the
mbrtowc(, str, 4, ) results to my contextless utf8towc(, str,
len) output, and I'm fixing every deviation between the two. I'm
currently trying to figure out why 0xeda080 _isn't_ 0xd800. (glibc
translates wc 0xd800 as f8a08a83 but it's less than  so
https://en.wikipedia.org/wiki/UTF-8 says it should be 3 bytes and I'm
CONFUSED...)

(Context-related edge cases aside, I want utf8 support enabled
regardless of locale and the glibc performance of its multibyte code is
_terrible_, so this is worth doing anyway.)

Rob
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net