#2  0x00003fffa1e4d9ac in g_logv (log_domain=0x3fffa21af598 "GLib-GIO", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at gmessages.c:1318
        domain = 0x0
        data = 0x0
        depth = 1
        log_func = 0x3fffa1e4d3f0 <g_log_default_handler>
        domain_fatal_mask = <optimized out>
        masquerade_fatal = <optimized out>
        test_level = 18
        was_fatal = <optimized out>
        was_recursion = <optimized out>
        msg = 0x1002546ae00 "fail: Error accepting connection: Bad file descriptor"
        msg_alloc = 0x1002546ae00 "fail: Error accepting connection: Bad file descriptor"
        i = 4
#3  0x00003fffa1e4db00 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1359
        args = <optimized out>
#4  0x00003fffa20d42c0 in g_socket_service_ready (object=0x100253c24f0 [GThreadedSocketService], result=<optimized out>, user_data=<optimized out>) at gsocketservice.c:382
        listener = 0x100253c24f0 [GThreadedSocketService]
        service = 0x100253c24f0 [GThreadedSocketService]
        connection = 0x1002530c280 [GSocket]
        source_object = 0x0
        error = 0x10025411910



prints a g_warning() in g_socket_service_ready():


  connection = g_socket_listener_accept_finish (listener, result, &source_object, &error);
  if (error)
    { 
      if (!g_error_matches (error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
»···g_warning ("fail: %s", error->message);
      g_error_free (error);
    }



It is similar to bug 1255169. Reassigning to glib2.

It would be desired that glib2 doesn't issue g_criticals or g_warnings for external failures (only for bugs).

Can you file these types of things upstream please?

Hmm actually though...i would say that passing invalid FDs into glib is *program* error, and not runtime error.  Hence we're within our rights to abort(), not return a GError.

Is NM providing glib a bad socket fd?

I don't understand which file descriptor causes the error. But it's not at all clear that this filedescriptor was opened by NetworkManager and passed to glib -- it could also be an internal file descriptor, like from the D-Bus socket.

Also, it's not clear that at the moment when NM passed the filedescriptor to glib, that it was already EBADFD. I would doubt that, but cannot be sure either.

IO can fail. glib should not log warnings about that, but either report the error to the user or silently ignore the failure.


Anyway, let's see whether this reproduces, maybe we can gather more information.

probably the same issue is bug 1451236.
See https://bugzilla.redhat.com/show_bug.cgi?id=1451236#c7

*** Bug 1457166 has been marked as a duplicate of this bug. ***

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.