Red Hat Bugzilla – Bug 1011179
g_thread_new doesn't handle EAGAIN properly
Last modified: 2014-04-09 11:46:34 EDT
Description of problem:
I active VNC server and crashed.
Version-Release number of selected component:
cmdline: /usr/bin/seahorse --no-window
runlevel: N 5
Thread no. 1 (10 frames)
#2 g_thread_new at gthread.c:840
#3 g_get_worker_context at gmain.c:5499
#4 _ik_startup at inotify-kernel.c:221
#5 _ip_startup at inotify-path.c:119
#6 _ih_startup at inotify-helper.c:84
#7 try_class at giomodule.c:640
#8 _g_io_module_get_default_type at giomodule.c:734
#9 _g_local_directory_monitor_new at glocaldirectorymonitor.c:244
#10 seahorse_ssh_source_init at seahorse-ssh-source.c:348
#11 g_type_create_instance at gtype.c:1868
Created attachment 801818 [details]
Created attachment 801819 [details]
Created attachment 801820 [details]
Created attachment 801821 [details]
Created attachment 801822 [details]
Created attachment 801823 [details]
Created attachment 801824 [details]
Created attachment 801825 [details]
Created attachment 801826 [details]
This crash happened in:
#2 0x000000354d86f0b8 in g_thread_new (name=name@entry=0x354d8ba50d "gmain", func=func@entry=0x354d849750 <glib_worker_main>, data=data@entry=0x0) at gthread.c:840
It is caused by a g_error() in g_thread_new().
msg = 0x1800950 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable"
It seems that g_thread_new() should handle EAGAIN intelligently.
*** Bug 1068741 has been marked as a duplicate of this bug. ***
g_thread_new behaves as documented here:
* If the thread can not be created the program aborts. See
* g_thread_try_new() if you want to attempt to deal with failures.
If something in the kernel or glibc recently changed to make spurious failures of pthread_create much more common, that needs to be fixed there.
*** Bug 1076968 has been marked as a duplicate of this bug. ***
*** Bug 1069261 has been marked as a duplicate of this bug. ***