Runtime segfault on freebsd

[alexcrichton]

This code will segfault quickly on freebsd. Apparently something in phread_cond_signal is dereferencing NULL.

I have been unable to reproduce yet with equivalent C code, so I'm assuming this is a problem with the runtime somewhere.

extern crate libc;

unsafe fn test() {
  use libc::funcs::posix01::wait;
  let mut status = 0;
  match libc::fork() {
    -1 => { println!("failed fork"); }
     0 => { libc::_exit(0); }
     n => { assert!(wait::waitpid(n, &mut status, 0) != -1); }
  }
}

fn main() {
    spawn(proc() { unsafe { test() } });
    unsafe { test() }
}

$ rm *.core; for i in {1..10000}; do; echo $i; ./foo || break; done
1
2
3
$

GNU gdb (GDB) 7.6 [GDB v7.6 for FreeBSD]
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd9.1".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/home/alex/rust/foo...done.
[New process 100832]
[New process 100740]
[New Thread 801c06800 (LWP 100832)]
[New Thread 801c06400 (LWP 100740)]
Core was generated by `foo'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000800b4e3a3 in ?? () from /lib/libthr.so.3

Thread 2 (Thread 801c06400 (LWP 100740)):
#0  0x0000000800b5589c in ?? () from /lib/libthr.so.3
#1  0x0000000800b4bedc in ?? () from /lib/libthr.so.3
#2  0x0000000800b53d5c in ?? () from /lib/libthr.so.3
#3  0x00000000004d9707 in rt::cleanup::h82e5897460229b1bUob::v0.11.pre ()
#4  0x0000000000434041 in start::h33b829529c2e0e97epd::v0.11.pre ()
#5  0x0000000000433e14 in lang_start::h60adb6d42985a1f5yod::v0.11.pre ()
#6  0x000000000040599f in main ()

Thread 1 (Thread 801c06800 (LWP 100832)):
#0  0x0000000800b4e3a3 in ?? () from /lib/libthr.so.3
#1  0x0000000800b53fb4 in pthread_cond_signal () from /lib/libthr.so.3
#2  0x00000000004d87d4 in rt::bookkeeping::decrement::hf3ae6ac93e6a5febaib::v0.11.pre ()
#3  0x0000000000433b3d in task::spawn_opts::closure.7683 ()
#4  0x00000000004d216f in rt::thread::thread_start::h6d417d8e1de153f3WJ8::v0.11.pre ()
#5  0x0000000800b4a4a4 in ?? () from /lib/libthr.so.3
#6  0x0000000000000000 in ?? ()

[alexcrichton]

I am unconvinced that this is a rust bug. This C program exhibits the same bug:

#include <assert.h>
#include <fcntl.h>
#include <pthread.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

static pthread_mutex_t lock;
static pthread_cond_t cond;
static volatile int cnt = 0;

static void test() {
  int p = fork();
  assert(p >= 0);
  if (p == 0) {
    _exit(0);
  }
  int a = 1;
  assert(waitpid(p, &a, 0) == p);
  assert(WEXITSTATUS(a) == 0);
}

static void *child(void *arg) {
  test();

  assert(pthread_mutex_lock(&lock) == 0);
  cnt -= 1;
  if (cnt == 0) {
    assert(pthread_cond_signal(&cond) == 0);
  }
  assert(pthread_mutex_unlock(&lock) == 0);
  return arg;
}

int main() {
  assert(pthread_mutex_init(&lock, NULL) == 0);
  assert(pthread_cond_init(&cond, NULL) == 0);

  pthread_t c1, c2;
  cnt = 2;
  assert(pthread_create(&c1, NULL, child, NULL) == 0);
  assert(pthread_create(&c2, NULL, child, NULL) == 0);

  assert(pthread_mutex_lock(&lock) == 0);
  while (cnt != 0) {
    assert(pthread_cond_wait(&cond, &lock) == 0);
  }
  assert(pthread_mutex_unlock(&lock) == 0);

  pthread_join(c1, NULL);
  pthread_join(c2, NULL);
}

[alexcrichton]

I have submitted an upstream bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=188425

[ebfe]

Can't reproduce this anymore (FreeBSD 10.1-RC2). Apart from the debuginfo tests (gdb too old and no utf-8 support) and a probably bogus failure in run-pass/tcp-stress.rs make check passes.

[alexcrichton]

Our FreeBSD bot is still segfaulting regularly (http://buildbot.rust-lang.org/builders/auto-bsd-64-opt/), but perhaps it was a bug fixed upstream? They're running FreeBSD 10.0-RELEASE-p1, so perhaps we just need to upgrade?

[ebfe]

@alexcrichton Upgrading seems a good idea. I have been running rust on FreeBSD for a few weeks now without major problems. I'm not sure at what point the random segfaults disappeared, but it might have happened before I upgraded to a 10.1 prerelease. Upgarding to the latest 10.0 patch level might be worth a try.

[alexcrichton]

I've upgraded our buildbot to 10.1-RC2 and I'll watch the queue for a few days to see if it's all green, and then we can close this and re-gate on bsd.