bug? sysinfo() and getopt_long() misbehavior

bug? sysinfo() and getopt_long() misbehavior

[orc]

I have built a musl-enabled system and encountered some bugs:

- sysinfo() incorrectly works. The result is busybox' free misbehaving:
% ./busybox free -m
             total         used         free       shared      buffers
Mem:           476          476            0          183        10489
-/+ buffers:      17592186034402        10489
Swap:        10135        10135            0

gdb shows garbage in struct after free calls sysinfo() with musl.

Reproducible with:
% cat procs.c 
#include <stdio.h>
#include <sys/sysinfo.h>

int main(void)
{
	struct sysinfo info;

	if(sysinfo(&info) == 0)
		printf("procs: %d\n", info.procs);
	return 0;
}
% gcc procs.c # glibc
% ./a.out
procs: 120
% musl-gcc procs.c # musl
% ./a.out
procs: -149225472

- (did not investigated properly) possible getopt_long() misbehavior, or
  just miscompile. The result is that iptables and gnu sed misbehaving
  at command line arguments:
% sed -i '/test/d' ttnosuchfile
sed: can't find label for jump to `tnosuchfile'
% sed '/test/d' -i ttnosuchfile
sed: can't read -i: No such file or directory
sed: can't read ttnosuchfile: No such file or directory
# iptables -vnL
iptables v1.4.12.1: unknown arguments found on commandline
Try `iptables -h' or 'iptables --help' for more information.
# iptables --version
iptables v1.4.12.1: unknown arguments found on commandline
Try `iptables -h' or 'iptables --help' for more information.

Both sed and iptables were compiled with -D_GNU_SOURCE defined.

Unfortunately I don't actually know how to fix these two.

Re: bug? sysinfo() and getopt_long() misbehavior

[Rich Felker]

On Fri, Jun 08, 2012 at 12:51:48AM +0800, orc wrote:
> I have built a musl-enabled system and encountered some bugs:
> 
> - sysinfo() incorrectly works. The result is busybox' free misbehaving:

Thanks for the catch. Apparently the structure definition was bogus
and was not intended for direct use with the linux sysinfo syscall.
It's fixed in git.

> - (did not investigated properly) possible getopt_long() misbehavior, or
>   just miscompile. The result is that iptables and gnu sed misbehaving
>   at command line arguments:
> % sed -i '/test/d' ttnosuchfile
> sed: can't find label for jump to `tnosuchfile'

My GNU sed build does not exhibit this behavior. It's linked with an
older musl, but the getopt code has not changed. Is it possible you
did anything odd building musl (editing the makefile/cflags)? Does the
same happen if you static link sed? If your answers to these questions
suggest a problem in musl, I'll rebuild sed and see if I can reproduce
it.

> % sed '/test/d' -i ttnosuchfile
> sed: can't read -i: No such file or directory
> sed: can't read ttnosuchfile: No such file or directory

This is to be expected. Options must come before non-option arguments.
The glibc behavior to the contrary is broken and non-conformant.

> # iptables -vnL
> iptables v1.4.12.1: unknown arguments found on commandline
> Try `iptables -h' or 'iptables --help' for more information.
> # iptables --version
> iptables v1.4.12.1: unknown arguments found on commandline
> Try `iptables -h' or 'iptables --help' for more information.
> 
> Both sed and iptables were compiled with -D_GNU_SOURCE defined.
> 
> Unfortunately I don't actually know how to fix these two.

I'm suspecting something is broken with respect to dynamic linking...
Are you using an old version of binutils? Did you remove or replace
-Bsymbolic-functions with something else?

Rich

Re: bug? sysinfo() and getopt_long() misbehavior

[orc]

On Thu, 7 Jun 2012 23:12:43 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Fri, Jun 08, 2012 at 12:51:48AM +0800, orc wrote:
> > I have built a musl-enabled system and encountered some bugs:
> > 
> > - sysinfo() incorrectly works. The result is busybox' free
> > misbehaving:
> 
> Thanks for the catch. Apparently the structure definition was bogus
> and was not intended for direct use with the linux sysinfo syscall.
> It's fixed in git.
Thanks!
> 
> > - (did not investigated properly) possible getopt_long()
> > misbehavior, or just miscompile. The result is that iptables and
> > gnu sed misbehaving at command line arguments:
> > % sed -i '/test/d' ttnosuchfile
> > sed: can't find label for jump to `tnosuchfile'
> 
> My GNU sed build does not exhibit this behavior. It's linked with an
> older musl, but the getopt code has not changed. Is it possible you
> did anything odd building musl (editing the makefile/cflags)? Does the
> same happen if you static link sed? If your answers to these questions
> suggest a problem in musl, I'll rebuild sed and see if I can reproduce
> it.
> 
> > % sed '/test/d' -i ttnosuchfile
> > sed: can't read -i: No such file or directory
> > sed: can't read ttnosuchfile: No such file or directory
> 
> This is to be expected. Options must come before non-option arguments.
> The glibc behavior to the contrary is broken and non-conformant.
Yes, I expected that glibc encourages wrong behavior.
Sorry, that was my fault: I actually *cross-compiled* sed and it's
autohell misdetected something during it (as it usually happens). When
native-compiling, problem gone away. (I think the same will be with
e2fsprogs, their cross-compiled versions die with GPF on target)
> 
> > # iptables -vnL
> > iptables v1.4.12.1: unknown arguments found on commandline
> > Try `iptables -h' or 'iptables --help' for more information.
> > # iptables --version
> > iptables v1.4.12.1: unknown arguments found on commandline
> > Try `iptables -h' or 'iptables --help' for more information.
> > 
> > Both sed and iptables were compiled with -D_GNU_SOURCE defined.
> > 
> > Unfortunately I don't actually know how to fix these two.
> 
> I'm suspecting something is broken with respect to dynamic linking...
> Are you using an old version of binutils? Did you remove or replace
> -Bsymbolic-functions with something else?
Binutils 2.20, musl compiled with -Bsymbolic-functions. But statically
or dynamically linked iptables still rejects to accept arguments.
It required ugly fix to work, mostly same as iproute2, removing some
non-conformant extensions, correct headers, maybe there is a fault. It
also expects somewhere that we have glibc (#ifdef __GLIBC__) headers.
Maybe it's code is non-conformant in whole. I will try to see where it
fails on host.
> 
> Rich

Re: bug? sysinfo() and getopt_long() misbehavior

[orc]

> Binutils 2.20, musl compiled with -Bsymbolic-functions. But statically
> or dynamically linked iptables still rejects to accept arguments.
> It required ugly fix to work, mostly same as iproute2, removing some
> non-conformant extensions, correct headers, maybe there is a fault. It
> also expects somewhere that we have glibc (#ifdef __GLIBC__) headers.
> Maybe it's code is non-conformant in whole. I will try to see where it
> fails on host.
Iptables fails because it sets optind to zero and getopt_long
immidately returns with -1 in the first line (argv[0][0] !=
'-'). But problem does not fixed with just removing 'optind = 0;' from
source code.
For what reason one can set optind to zero?

Re: bug? sysinfo() and getopt_long() misbehavior

[Rich Felker]

On Fri, Jun 08, 2012 at 08:12:06PM +0800, orc wrote:
> > Binutils 2.20, musl compiled with -Bsymbolic-functions. But statically
> > or dynamically linked iptables still rejects to accept arguments.
> > It required ugly fix to work, mostly same as iproute2, removing some
> > non-conformant extensions, correct headers, maybe there is a fault. It
> > also expects somewhere that we have glibc (#ifdef __GLIBC__) headers.
> > Maybe it's code is non-conformant in whole. I will try to see where it
> > fails on host.
> Iptables fails because it sets optind to zero and getopt_long
> immidately returns with -1 in the first line (argv[0][0] !=
> '-'). But problem does not fixed with just removing 'optind = 0;' from
> source code.
> For what reason one can set optind to zero?

I believe it's a common but non-portable way of restarting option
scanning. Of course that would make no sense if this is the first scan
of options anyway. I'll try to look into what's going wrong here..

Rich

Re: bug? sysinfo() and getopt_long() misbehavior

[orc]

On Fri, 8 Jun 2012 10:12:39 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> I believe it's a common but non-portable way of restarting option
> scanning. Of course that would make no sense if this is the first scan
> of options anyway. I'll try to look into what's going wrong here..
> 
> Rich

What is the status of this issue?
Tried to workaround it in iptables itself, but failed, too many logic
around getopt_long plus it uses gnu extension that current getopt_long
does not support.

Re: bug? sysinfo() and getopt_long() misbehavior

[Isaac Dunham]

On Thu, 7 Jun 2012 23:12:43 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> > - (did not investigated properly) possible getopt_long()
> > misbehavior, or just miscompile. The result is that iptables and
> > gnu sed misbehaving at command line arguments:
> > % sed -i '/test/d' ttnosuchfile
> > sed: can't find label for jump to `tnosuchfile'
> 
> My GNU sed build does not exhibit this behavior. It's linked with an
> older musl, but the getopt code has not changed. Is it possible you
> did anything odd building musl (editing the makefile/cflags)? Does the
> same happen if you static link sed? If your answers to these questions
> suggest a problem in musl, I'll rebuild sed and see if I can reproduce
> it.
> 
> > % sed '/test/d' -i ttnosuchfile
> > sed: can't read -i: No such file or directory
> > sed: can't read ttnosuchfile: No such file or directory
> 
> This is to be expected. Options must come before non-option arguments.
> The glibc behavior to the contrary is broken and non-conformant.
sed -e '...' -i ...
is more conventional, and might persuade getopt_long to cooperate...

> > # iptables -vnL
> > iptables v1.4.12.1: unknown arguments found on commandline
> > Try `iptables -h' or 'iptables --help' for more information.
> > # iptables --version
> > iptables v1.4.12.1: unknown arguments found on commandline
> > Try `iptables -h' or 'iptables --help' for more information.
> > 
> > Both sed and iptables were compiled with -D_GNU_SOURCE defined.
> > 
> > Unfortunately I don't actually know how to fix these two.
> 
> I'm suspecting something is broken with respect to dynamic linking...
> Are you using an old version of binutils? Did you remove or replace
> -Bsymbolic-functions with something else?

Definitely not, I'd say--that doesn't just misbehave, it will die with
a SIGILL before it gets to main().

Re: bug? sysinfo() and getopt_long() misbehavior

[Rich Felker]

On Thu, Jun 07, 2012 at 10:37:07PM -0700, Isaac Dunham wrote:
> > > Unfortunately I don't actually know how to fix these two.
> > 
> > I'm suspecting something is broken with respect to dynamic linking...
> > Are you using an old version of binutils? Did you remove or replace
> > -Bsymbolic-functions with something else?
> 
> Definitely not, I'd say--that doesn't just misbehave, it will die with
> a SIGILL before it gets to main().

Replacing -Bsymbolic-functions with -Bsymbolic to get it to "work" on
an old toolchain will prevent getopt and anything that shares global
vars between libc and the main program from working. That's what I
initially suspected.

Rich