Bug 1011179 - g_thread_new doesn't handle EAGAIN properly
Summary: g_thread_new doesn't handle EAGAIN properly
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:75997a8f2e1ab18ef5fa738cf26...
: 1068741 1069261 1076968 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-23 17:43 UTC by Onuralp SEZER
Modified: 2014-04-09 15:46 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-03-03 20:30:12 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
File: backtrace (34.28 KB, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: cgroup (159 bytes, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: core_backtrace (15.25 KB, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: dso_list (10.48 KB, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: environ (3.28 KB, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: limits (1.29 KB, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: maps (48.75 KB, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: open_fds (782 bytes, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
File: proc_pid_status (939 bytes, text/plain)
2013-09-23 17:43 UTC, Onuralp SEZER 		no flags Details
View All

Description Onuralp SEZER 2013-09-23 17:43:14 UTC 
Description of problem:
I active VNC server and crashed. 

Version-Release number of selected component:
seahorse-3.9.91-1.fc20

Additional info:
reporter:       libreport-2.1.7
backtrace_rating: 4
cmdline:        /usr/bin/seahorse --no-window
crash_function: g_thread_new
executable:     /usr/bin/seahorse
kernel:         3.11.1-300.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
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
Comment 1 Onuralp SEZER 2013-09-23 17:43:19 UTC 
Created attachment 801818 [details]
File: backtrace
Comment 2 Onuralp SEZER 2013-09-23 17:43:26 UTC 
Created attachment 801819 [details]
File: cgroup
Comment 3 Onuralp SEZER 2013-09-23 17:43:30 UTC 
Created attachment 801820 [details]
File: core_backtrace
Comment 4 Onuralp SEZER 2013-09-23 17:43:35 UTC 
Created attachment 801821 [details]
File: dso_list
Comment 5 Onuralp SEZER 2013-09-23 17:43:38 UTC 
Created attachment 801822 [details]
File: environ
Comment 6 Onuralp SEZER 2013-09-23 17:43:42 UTC 
Created attachment 801823 [details]
File: limits
Comment 7 Onuralp SEZER 2013-09-23 17:43:47 UTC 
Created attachment 801824 [details]
File: maps
Comment 8 Onuralp SEZER 2013-09-23 17:43:51 UTC 
Created attachment 801825 [details]
File: open_fds
Comment 9 Onuralp SEZER 2013-09-23 17:43:55 UTC 
Created attachment 801826 [details]
File: proc_pid_status
Comment 10 Stef Walter 2013-09-30 10:53:41 UTC 
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.
Comment 11 Carlos O'Donell 2014-03-03 18:54:31 UTC 
*** Bug 1068741 has been marked as a duplicate of this bug. ***
Comment 12 Matthias Clasen 2014-03-03 20:29:28 UTC 
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.
Comment 13 Stef Walter 2014-03-17 09:57:29 UTC 
*** Bug 1076968 has been marked as a duplicate of this bug. ***
Comment 14 Debarshi Ray 2014-04-09 15:46:34 UTC 
*** Bug 1069261 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.