Be careful with errno

I’m getting close to releasing version 3.3.11 of procps.  When it gets near that time, I generally browse again the Debian Bug Tracker for procps bugs. Bug number #733758 caught my eye.  With the free command if you used the s option before the c option, the s option failed, “seconds argument ‘N’ failed” where N was the number you typed in. The error should be for you trying to type letters for number of seconds. Seemed reasonably simple to test and simple to fix.

Take me to the code

The relevant code looks like this:

   case 's':
            flags |= FREE_REPEAT;
            args.repeat_interval = (1000000 * strtof(optarg, &endptr));
            if (errno || optarg == endptr || (endptr && *endptr))
                xerrx(EXIT_FAILURE, _("seconds argument `%s' failed"), optarg);

Seems pretty stock-standard sort of function. Use strtof() to convert the string into the float.

You need to check both errno AND optarg == endptr because:

  • A valid but large float means errno = ERANGE
  • A invalid float (e.g. “FOO”) means optarg == endptr

At first I thought the logic was wrong, but tracing through it was fine.  I then compiled free using the upstream git source, the program worked fine with s flag with no c flag. Doing a diff between the upstream HEAD and Debian’s 3.3.10 source showed nothing obvious.

I then shifted the upstream git to 3.3.10 too and re-compiled. The Debian source failed, the upstream parsed the s flag fine. I ran diff, no change. I ran md5sum, the hashes matched; what is going on here?

I’ll set when I want

The man page says in the case of under/overflow “ERANGE is stored in errno”. What this means is if there isn’t and under/overflow then errno is NOT set to 0, but its just not set at all. This is quite useful when you have a chain of functions and you just want to know something failed, but don’t care what.

Most of the time, you generally would have a “Have I failed?” test and then check errno for why. A typical example is socket calls where anything less than 0 means failure. You check the return value first and then errno. strtof() is one of those funny ones where most people check errno directly; its simpler than checking for +/- HUGE_VAL. You can see though that there are traps.

What’s the difference?

OK, so a simple errno=0 above the call fixes it, but why would the Debian source tree have this failure and the upstream not? Even with the same code? The difference is how they are compiled.

The upstream compiles free like this:

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./include -DLOCALEDIR=\"/usr/local/share/locale\" -Iproc -g -O2 -MT free.o -MD -MP -MF .deps/free.Tpo -c -o free.o free.c
mv -f .deps/free.Tpo .deps/free.Po
/bin/bash ./libtool --tag=CC --mode=link gcc -std=gnu99 -Iproc -g -O2 ./proc/libprocps.la -o free free.o strutils.o fileutils.o -ldl
libtool: link: gcc -std=gnu99 -Iproc -g -O2 -o .libs/free free.o strutils.o fileutils.o ./proc/.libs/libprocps.so -ldl

 

While Debian has some hardening flags:

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./include -DLOCALEDIR=\"/usr/share/locale\" -D_FORTIFY_SOURCE=2 -Iproc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -MT free.o -MD -MP -MF .deps/free.Tpo -c -o free.o free.c
mv -f .deps/free.Tpo .deps/free.Po
/bin/bash ./libtool --tag=CC --mode=link gcc -std=gnu99 -Iproc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security ./proc/libprocps.la -Wl,-z,relro -o free free.o strutils.o fileutils.o -ldl
libtool: link: gcc -std=gnu99 -Iproc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro -o .libs/free free.o strutils.o fileutils.o ./proc/.libs/libprocps.so -ldl

It’s not the compiling of free itself that is doing it, but the library. Most likely something that is called before the strtof() is setting errno which this code then falls into. In fact if you run the upstream free linked to the Debian procps library it fails.

Moral of the story is to set errno before the function is called if you are going to depend on it for checking if the function succeeded.

 

Linux 4.0 ate my docker images

I have previously written about the gitlab CI runners that use docker.  Yesterday I made some changes to procps and pushed them to gitlab which would then start the CI.  This morning I checked and it said build failed – ok, so that’s not terribly unusual. The output from the runner was:

gitlab-ci-multi-runner 0.3.3 (dbaf96f)
Using Docker executor with image csmall/testdebian ...
Pulling docker image csmall/testdebian ...
Build failed with Error: image csmall/testdebian: not found

Hmm, I know I have that image, it just must be the runner so, let’s see what images I have:

$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE

Now, I know I have images, I had about 10 or so of them, where did they go? I even looked in the /var/lib/docker directories and can see the json configs, what have you done with my images docker?

Read more Linux 4.0 ate my docker images

Sneak peek of top graphs

Jim has been busy as part of the procps-ng team that looks after top. Basically all the changes you find in top from around 2.7 or so are by him. Not satisfied enough with fixing top, making it faster and showing more fields, he has given us CPU and memory graphs.

He also thinks I don’t have enough colours (or as he would put it colors) on my top output so I’ve posted what the new top looks like for me so you can see the graphs and he can see my colours.

top, with colours
top, with colours

 

I think it is both colourful and useful addition. The colours have been available for a while now and the graphs will appear in the next upstream release of procps-ng.

 

procps-ng 3.3.9

Procps version 3.3.9 was released today.  As there has been some API changes and fixes which means the library has changed again.  There is a fine balance between fixing or enhancing library functions and keeping the API stable, with the added problem it wasn’t a terribly good one to start with.

Besides the API change, the following changes were made:

  • kernel namespaces support added to skill, pgrep, ps and top
  • pidof was reimplemented from scratch (replacing sysvinit pidof)
  • ps has configurable libselinux support (–enable-libselinux)
  • ps provides for display of systemd slice unit (–with-systemd)
  • free can once again report non-zero ‘shared’ memory
  • sysctl provides ‘–system’ to ignore missing /etc/sysctl.conf
  • watch interval capacity was increased – debian #720445
  • pwdx no longer fails in a nonexistent locale – debian #718766
  • top clarified summary area Mem/Swap stats – debian #718670
  • top batch mode -w (width) abend fixed – debian #721204
  • top man page removed ‘Bd/Ed’ mdoc macros – debian #725713
  • top no longer clears screen at exit – redhat #977561
  • top adapted to potential libnuma stderr message – redhat #998678
  • top added missing batch mode newline – redhat #1008674

Tar file is at sourceforge at https://sourceforge.net/projects/procps-ng/files/Production/

procps-ng 3.3.7 Released

procps-ng version 3.3.7 was released today.  It has some new and interesting features in the top program that Jim has been busy working on.  There is a new filter feature which can exclude fields that match a value for example. The remainder of the changes are small bug fixes and getting the compile warnings count down with -Wall enabled. The library revision was updated but this did not involve an API or ABI change.

procps-ng can be downloaded off the sourceforge page which has the current and previous releases stored there. Alternatively you can visit our gitorious page if git fetch is more your thing. Debian packages will be going into experimental until the freeze is over and we get things unblocked.