Process hangs on at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95

[dobos]

I'm working on a system that helps me debug student's submissions for programming course assignments. I want to build c code with gcc and run with gdb attached so that I can see memory handling problems my students make. I ran into the following interesting problem. The example below is obviously a wrong program, the issue here is handling the situation by WSL, not with the C code. Standard ubuntu xenial simply fails with a SIGSEGV.

Program:

#include <stdlib.h>
#include <stdio.h>

int main(int argc, char** argv)
{
  int i;
  FILE * f;
  double * m;

  f = (FILE*)(argv - 1);
  m = (double*)malloc(10000);

  for (i = 0; i < 100; i ++)
  {
     printf("%d ", i);
  }

  fclose(f);
}

I build with symbols:

$ gcc test.c -o test -g

If I run from the shell, the program hangs:

$ ./test

From withing gdb:

$ gdb
(gdb) file test
(gdb) run

At this point the program hangs, so press ctrl+c to interrupt)
gdb output:

__lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
95      ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.

Looking at the stack:

(gdb) bt

#0  __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x00007fffff09d3be in _IO_new_fclose (fp=0x7ffffffde1e0) at iofclose.c:56
#2  0x0000000000400612 in main (argc=1, argv=0x7ffffffde1e8) at test.c:18

This is probably a deadlock with stdout also, because the program above doesn't produce any output on the console though it should print out numbers from 0 to 99.

Expected behavior: instead of hanging at lowlevellock, the process should print output and then fail with segfault.

Version info

• Windows 10 Pro 1709 build 16299.431
• uname -a reports kernel as Linux XPS 4.4.0-43-Microsoft Will this be Open Source? #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
• Ubuntu 16.04.4 LTS
• gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
• GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1

[therealkenc]

Standard ubuntu xenial simply fails with a SIGSEGV.

Not for me. It hangs in 16.04.4 on Real Linux™, same as WSL. strace from RL here.

Here is a minimal repro:

#include <stdio.h>
int main(int argc, char** argv)
{
  printf("yo"); fclose((FILE*)(argv-1));
}

There is no segfault because *(argv-1) is mapped into memory. Glibc's fclose() assumes a valid FILE* is passed, but instead acts on garbage, and loops. yo is not printed to stdout because fclose() never returns and stdout never gets flushed.

Expected behavior: instead of hanging at lowlevellock, the process should print output and then fail with segfault.

No, the expected behaviour of that program is undefined and depends entirely on the internal details of the libc implementation you happen to be using. In our case that is (arbitrarily) glibc 2.23-0ubuntu10. It might behave in a different undefined way using glibc 2.31-0ubuntu13 at some future date. It might behave in a different undefined way still with musl (I hear it makes your printer catch fire).