1

I get the following error while installing glib.

ERROR:thread.c:147:test_thread4: assertion failed: (thread == NULL).

What is the issue and how can I fix it?

0

1 Answer 1

2

Remember that make check in glib comes in last. make check depends on the desktop-file-utils-0.20, which in turn depend on an installed glib, so that one should make sure that the desktop-file-utils are installed, working and at a correct version before running make check. The canonical way would be to first install the new glibc, then desktop-file-utils, and then, at the very end, do make check.

In general, an error during check is a reason to worry, at least in a professional setting. Failure of a test may mean that some particular condition can bring the system to its knees, even if the system runs fine 99.99% of the time.

In this particular case, you can directly look into the source code of glib to understand what is happening. Here is the relevant function:

/* test that thread creation fails as expected,
 * by setting RLIMIT_NPROC ridiculously low
 */
static void
test_thread4 (void)
{
#ifdef HAVE_PRLIMIT
  struct rlimit ol, nl;
  GThread *thread;
  GError *error;
  gint ret;

  getrlimit (RLIMIT_NPROC, &nl);
  nl.rlim_cur = 1;

  if ((ret = prlimit (getpid(), RLIMIT_NPROC, &nl, &ol)) != 0)
    g_error ("prlimit failed: %s\n", g_strerror (ret));

  error = NULL;
  thread = g_thread_try_new ("a", thread1_func, NULL, &error);
  g_assert (thread == NULL);
  g_assert_error (error, G_THREAD_ERROR, G_THREAD_ERROR_AGAIN);
  g_error_free (error);

  if ((ret = prlimit (getpid (), RLIMIT_NPROC, &ol, NULL)) != 0)
    g_error ("resetting RLIMIT_NPROC failed: %s\n", g_strerror (ret));
#endif
}

The error occurs ad the line

g_assert( thread == NULL ) ;

The test function changes the RLIMIT_PROC to a value of 1 (nl.rlim_cur=1, which limits the number of threads the current process can have). With that setting, creation of a new thread (g_thread_try_new() call) should fail and return NULL. For some reason, this does not happen.

Either there is a bug in the test suite, or a problem with glibc, or there was a problem correctly building glibc. In any case, incorrect return values from thread management library calls would make me very nervous.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .