Bug 116587 - [EFL] Layout Test Error related to "_ecore_main_fd_handlers_bads_rem() No bad fd found. Maybe a foreign fd from glib?"
Summary: [EFL] Layout Test Error related to "_ecore_main_fd_handlers_bads_rem() No bad...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 135831
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-21 19:08 PDT by Gyuyoung Kim
Modified: 2017-03-11 10:32 PST (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gyuyoung Kim 2013-05-21 19:08:16 PDT
EFL Buildbot prints lots of error logs on some test cases. It looks this error looks like EFL specific problem.

13:43:41.353 16645 worker/0 http/tests/websocket/tests/hybi/close-on-navigate-new-location.html output stderr lines:
13:43:41.369 16645   ERR<23756>:ecore ecore_main.c:1531 _ecore_main_fd_handlers_bads_rem() Removing bad fds
13:43:41.369 16645   ERR<23756>:ecore ecore_main.c:1573 _ecore_main_fd_handlers_bads_rem() No bad fd found. Maybe a foreign fd from glib?
13:43:41.369 16645   ERR<23756>:ecore ecore_main.c:1531 _ecore_main_fd_handlers_bads_rem() Removing bad fds
13:43:41.369 16645   ERR<23756>:ecore ecore_main.c:1573 _ecore_main_fd_handlers_bads_rem() No bad fd found. Maybe a foreign fd from glib?
Comment 1 Grzegorz Czajkowski 2013-05-22 02:08:20 PDT
This error message is being printed while typing to the input fields. It can be reproduced in MiniBrowser and EWebLauncher as well.
Comment 2 Chris Dumez 2013-05-22 02:09:47 PDT
Yes, they have been there for a while, I have noticed them as well. It would be good to fix them.
Comment 3 Seokju Kwon 2013-09-02 02:10:30 PDT
Also on remote web inspector :-(
Is there any plan to fix it?
Comment 4 Gyuyoung Kim 2013-09-02 02:45:26 PDT
(In reply to comment #3)
> Also on remote web inspector :-(
> Is there any plan to fix it?

This bug isn't my top priority now. So, If there is volunteer, I'm willing to give up this bug. :) Do you want to fix this bug ?
Comment 5 Ryuan Choi 2014-08-11 22:34:13 PDT
I traced the bad fd and it looks because g_main_context_query returns bad fd which is already closed.

I reproduced it as clicking "reload" button frequently on the MiniBrowser (which loads google.com)

And when select (in ecore_glib.c) is failed, one of fd which returns g_main_context_query got EBADF.

In strace, I got below log. (42 is bad fd in below log)

[pid 25226] socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, IPPROTO_IP <unfinished ...>
[pid 25227] select(33, [30 32], NULL, NULL, NULL <unfinished ...>
[pid 25226] <... socket resumed> )      = 42
[pid 25217] read(18,  <unfinished ...>
[pid 25226] fcntl(42, F_GETFL <unfinished ...>
[pid 25217] <... read resumed> "\1\0\0\0", 4) = 4
[pid 25226] <... fcntl resumed> )       = 0x2 (flags O_RDWR)
[pid 25217] read(18,  <unfinished ...>
[pid 25226] fcntl(42, F_SETFL, O_RDWR|O_NONBLOCK <unfinished ...>
[pid 25217] <... read resumed> "W", 1)  = 1
[pid 25226] <... fcntl resumed> )       = 0
[pid 25217] read(18, 0xa863d8, 4)       = -1 EAGAIN (Resource temporarily unavailable)
[pid 25226] connect(42, {sa_family=AF_INET, sin_port=htons(8080), sin_addr=inet_addr("168.219.61.252")}, 16 <unfinished ...>
[pid 25217] fcntl(3, F_GETFD)           = 0x1 (flags FD_CLOEXEC)
[pid 25226] <... connect resumed> )     = -1 EINPROGRESS (Operation now in progress)

...

[pid 25217] select(32, [3 31], [], [], {0, 0} <unfinished ...>
[pid 25226] <... write resumed> )       = 8
[pid 25217] <... select resumed> )      = 0 (Timeout)
[pid 25217] recvfrom(12, 0xab34e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 25226] close(42 <unfinished ...>

...

[pid 25227] <... recvmsg resumed> 0x7f668f139b60, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 25226] select(44, [3 24 42 43], [], [], {0, 0} <unfinished ...>
[pid 25227] select(33, [30 32], NULL, NULL, NULL <unfinished ...>
[pid 25226] <... select resumed> )      = -1 EBADF (Bad file descriptor)
[pid 25217] fcntl(3, F_GETFD <unfinished ...>
[pid 25226] write(2, "_ecore_glib_select__locked **\n", 30_ecore_glib_select__locked **
 <unfinished ...>
[pid 25217] <... fcntl resumed> )       = 0x1 (flags FD_CLOEXEC)
[pid 25226] <... write resumed> )       = 30
[pid 25217] poll([{fd=12, events=POLLIN|POLLOUT}], 1, 4294967295 <unfinished ...>
[pid 25226] fcntl(24, F_GETFD <unfinished ...>
[pid 25217] <... poll resumed> )        = 1 ([{fd=12, revents=POLLOUT}])
[pid 25226] <... fcntl resumed> )       = 0x1 (flags FD_CLOEXEC)
[pid 25217] writev(12, [{"\22\0\16\0\3\0@\4'\0\0\0\24\1\0\0\10\0\0\0\36\0\0\0Google ("..., 336}, {NULL, 0}, {"", 0}], 3 <unfinished ...>
[pid 25226] fcntl(42, F_GETFD <unfinished ...>
[pid 25217] <... writev resumed> )      = 336
[pid 25226] <... fcntl resumed> )       = -1 EBADF (Bad file descriptor)
[pid 25217] recvfrom(12,  <unfinished ...>
[pid 25226] write(2, "_ecore_glib_context_trace : 42 #"..., 37_ecore_glib_context_trace : 42 #### 
 <unfinished ...>
[pid 25217] <... recvfrom resumed> "\34\0\36\6\3\0@\4'\0\0\0\207;\322\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 0, NULL, NULL) = 192
[pid 25226] <... write resumed> )       = 37
[pid 25217] recvfrom(12,  <unfinished ...>
[pid 25226] fcntl(43, F_GETFD <unfinished ...>
[pid 25217] <... recvfrom resumed> 0xab34e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
[pid 25226] <... fcntl resumed> )       = 0x1 (flags FD_CLOEXEC)

I don't know why glib returns this fd, but glib(g_main_context_iterate) looks not check the results of poller.
Comment 6 Csaba Osztrogonác 2014-11-03 04:31:30 PST
Is there any plan to fix this old bug on EFL side?

It seems something is broken near the websocket implementation,
which caused the test flakiness, and I assume the non-working
inspector server is related to this bug too - https://bugs.webkit.org/show_bug.cgi?id=125073
Comment 7 Michael Catanzaro 2017-03-11 10:32:47 PST
Closing this bug because the EFL port has been removed from trunk.

If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.