the kernel used on this builder is a 2.6.24 version

Please also attach the debug output. It looks this way for me:

$ ./gdbus-threading 
/gdbus/delivery-in-thread: OK
/gdbus/method-calls-in-thread: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS OK


Also please run the test case with G_DBUS_DEBUG=all in the environment ... WARNING: it will generate a ton of output on stdout (ca. 45,000 lines) but should still succeed.

The builder log at the hang time is:

"TEST: gdbus-peer... (pid=26946)
  /gdbus/peer-to-peer:                                                 OK
  /gdbus/delayed-message-processing:                                   OK
  /gdbus/nonce-tcp:                                                    OK
  /gdbus/tcp-anonymous:                                                OK
  /gdbus/credentials:                                                  OK
  /gdbus/overflow:                                                     OK
  /gdbus/codegen-peer-to-peer: "

it hangs there until being stopped

Created attachment 203407 [details]
test debug log

the log is from a G_DBUS_DEBUG=all run of gdbus-threading in a builder environment which was hanging...

in gdbus-threading, we see this:

static gpointer
test_delivery_in_thread_func (gpointer _data)
{
  ...


  g_main_loop_quit (loop);

  return NULL;
}

static void
test_delivery_in_thread (void)
{
  GThread *thread;

  thread = g_thread_new ("deliver",
                         test_delivery_in_thread_func,
                         NULL);

  /* run the event loop - it is needed to dispatch D-Bus messages */
  g_main_loop_run (loop);

  g_thread_join (thread);
}


not cool.

I'm guessing that the old kernel was somewhat more likely to allow the created thread to execute to completion before returning control to the main thread than new kernels are...

Created attachment 203416 [details] [review]
gdbus tests: remove buggy use of GMainLoop

g_main_loop_quit() only quits mainloops that are currently running --
not ones that may run in the future.  The way the gdbus-threading tests
are written can possibly result in a call to g_main_loop_quit() before
g_main_loop_run() has started.

The mainloops aren't actually used for anything other than signalling
the completion of the threads, so just use g_thread_join() for that.

Many other GDBus testcases use GMainLoop in the same broken way... this is probably entirely the cause of all the reported deadlocks we've been hearing about.

/gdbus/codegen-peer-to-peer sits spinning in the while loop at the top of codegen_test_peer() because codegen_service_thread_func() creates its main loop (service_loop) which then gets NULL'd out by the main thread here:

  service_thread = g_thread_new ("codegen_test_peer",
                                 codegen_service_thread_func,
                                 NULL);
  service_loop = NULL;
  while (service_loop == NULL)
    g_thread_yield ();

Created attachment 203472 [details] [review]
Initialize service_loop before running the service thread

This seems to fix the hang in /gdbus/codegen-peer-to-peer

Comment on attachment 203416 [details] [review]
gdbus tests: remove buggy use of GMainLoop

Attachment 203416 [details] pushed as 0a7930d - gdbus tests: remove buggy use of GMainLoop

The following fix has been pushed:
162bafe Initialize service_loop before running the service thread

Created attachment 203547 [details] [review]
Initialize service_loop before running the service thread

Bug:

This got closed by accident and we've yet to go through all the testcases systematically ensuring that they're safe, so I'll reopen it.

nothing more happened here, so lets close it after all.