Re: [E-devel] Enlightenment on OpenIndiana

2017-04-13 Thread Aurélien Larcher 
Hi,

With the help of Vincent I disabled the epoll check for solaris based
> systems now. This will be part of the 1.19 release I prepare right now.
>

Thank you, this is perfect for now.

>
> Once it is out I would appreciate if you could test it. If we missed
> anything else we could put that into the 1.19.1 release.
>

If will bump our package to 1.19 next week.
There is an ongoing discussion to decide if epoll should be "fixed" or if
we should use event port for EFL.
I am in touch with Vincent on a regular basis so you'll be updated as soon
as something comes out.

Kind regards

Aurelien



>
> regards
> Stefan Schmidt
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
---
Praise the Caffeine embeddings
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment on OpenIndiana

2017-04-12 Thread Stefan Schmidt 
Hello.

On 04/11/2017 11:27 PM, Aurélien Larcher wrote:
> Hi,
> sorry for the very late reply, I have been busy with other tasks... and
> thank you very much for your substantial answers.
> I followed up off-list with Vincent Torri in the past weeks.
>
> i don't know what to say... both of the traces i see smell to me like really
>> nasty OS issues at a glance. show me more info to say they are not, but
>> this
>> would imply opensolaris is really badly broken. especially getpid()
>> hanging.
>>
>
> Better late than never: I found the origin of the our problems: it is epoll.
> Joyent introduced an implementation of epoll at some point but if you look
> at:
>
> https://us-east.manta.joyent.com/smartosman/public/man5/epoll.5.html
>
> it is not considered a first class citizen and is deliberately avoided on
> illumos.
>
> In src/lib/ecore/ecore_main.c, epoll is used if the header exists, so as
> soon as sys/epoll.h appeared in the tree, it broke our packages.
>
> I have changed the ifdef, rebuilt EFL 1.18.4, tested elementary and
> terminology 1.0, all is good.
> Thank you very much for your kind help.

With the help of Vincent I disabled the epoll check for solaris based 
systems now. This will be part of the 1.19 release I prepare right now.

Once it is out I would appreciate if you could test it. If we missed 
anything else we could put that into the 1.19.1 release.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment on OpenIndiana

2017-04-11 Thread Aurélien Larcher 
Hi,
sorry for the very late reply, I have been busy with other tasks... and
thank you very much for your substantial answers.
I followed up off-list with Vincent Torri in the past weeks.

i don't know what to say... both of the traces i see smell to me like really
> nasty OS issues at a glance. show me more info to say they are not, but
> this
> would imply opensolaris is really badly broken. especially getpid()
> hanging.
>

Better late than never: I found the origin of the our problems: it is epoll.
Joyent introduced an implementation of epoll at some point but if you look
at:

https://us-east.manta.joyent.com/smartosman/public/man5/epoll.5.html

it is not considered a first class citizen and is deliberately avoided on
illumos.

In src/lib/ecore/ecore_main.c, epoll is used if the header exists, so as
soon as sys/epoll.h appeared in the tree, it broke our packages.

I have changed the ifdef, rebuilt EFL 1.18.4, tested elementary and
terminology 1.0, all is good.
Thank you very much for your kind help.

Aurelien



>
> > Kind regards
> >
> > Aurelien
> >
> > 
> 
> > helios> pstack `pgrep terminology`
> > 12876:terminology
> > -  lwp# 1 / thread# 1  
> >  feeff915 getpid   (fafc, 400fa919, 8046118, fe9c8db9) + 15
> >  fe9c8fef ecore_main_loop_begin (febf4409) + 36f
> >  febf4417 elm_run  (0, 0, 752f0031, 81414f0, 40001415, 0) + 17
> >  0806a559 elm_main (1, 804769c, 8047668, 806aa0d, 80bc000, 8047648) + e59
> >  0806aa26 main (804765c, fef786e8, 8047690, 8062cb3, 1, 804769c) + 36
> >  08062cb3 _start   (1, 80477fc, 0, 8047808, 8047824, 804782f) + 83
> > -  lwp# 2 / thread# 2  
> >  feefb5b9 lwp_park (0, 0, 0)
> >  feef55f8 cond_wait_queue (fe698408, fe6983ec, 0, 1, 83088f8, 83088f8) +
> 6a
> >  feef5c70 __cond_wait (fe698408, fe6983ec, fe657c9a, fe66b000,
> > fef6e000, fe698408) + 8f
> >  feef5cc4 cond_wait (fe698408, fe6983ec, fe50123b, fe5cf036, fe65965a,
> > fe66b000) + 2e
> >  feef5d0d pthread_cond_wait (fe698408, fe6983ec, fdb9ef98, fe5ced59) + 24
> >  fe5cedde evas_thread_worker_func (0, 2, fdb9efc8, fedd1429, feed7c7e,
> 3) + 9e
> >  fedd1432 _eina_internal_call (80bf5c0, 0, 0, 0) + 32
> >  feefb3cb _thrp_setup (fda90240) + 88
> >  feefb560 _lwp_start (fda90240, 0, 0, 0, 0, 0)
> > -  lwp# 3 / thread# 3  
> >  fedd1400 _eina_internal_call(), exit value = 0x
> > ** zombie (exited, not detached, not yet joined) **
> > -  lwp# 4 / thread# 4  
> >  fedd1400 _eina_internal_call(), exit value = 0x
> > ** zombie (exited, not detached, not yet joined) **
> > -  lwp# 5 / thread# 5  
> >  feefb5b9 lwp_park (0, 0, 0)
> >  feeef15e sema_wait (81428d8, fef726c0, fd97ef28, feef41d9, fee0c000,
> > 81428d8) + 19
> >  feee22cd sem_wait (81428d8, fee10018, fda90a40, feef3e46) + 35
> >  fedd24af eina_thread_queue_wait (8142898, fd97ef7c, fd97ef98, fe5c5c9c)
> + 3f
> >  fe5c5cbf _evas_common_scale_sample_thread (0, 5, fd97efc8, fedd1429,
> > feed7c7e, 3) + 3f
> >  fedd1432 _eina_internal_call (8199d80, 0, 0, 0) + 32
> >  feefb3cb _thrp_setup (fda90a40) + 88
> >  feefb560 _lwp_start (fda90a40, 0, 0, 0, 0, 0)
> > -  lwp# 6 / thread# 6  
> >  feeffcc5 pollsys  (fb87fc30, 1, fb87fd68, 0)
> >  fee9730f pselect  (13, fb87fde0, fb87fe60, fb87fee0, fb87fd68, 0) + 1bf
> >  fee97618 select   (13, fb87fde0, fb87fe60, fb87fee0, fb87fdd8,
> 41197acd) + 8e
> >  fe9bde8f _timer_tick_core (0, 83a7f10, fb87ff98, fe9cf948, fee0c000,
> > 813a988) + 15f
> >  fe9cf96c _ecore_direct_worker (83a7f10, 6, fb87ffc8, fedd1429,
> > feed7c7e, 3) + 3c
> >  fedd1432 _eina_internal_call (813a988, 0, 0, 0) + 32
> >  feefb3cb _thrp_setup (fda91a40) + 88
> >  feefb560 _lwp_start (fda91a40, 0, 0, 0, 0, 0)
> >
> > 
> 
> > helios> pstack 9171
> > 9171:elementary_test
> > -  lwp# 1 / thread# 1  
> >  feeff475 __so_recvmsg (a, 80473f8, 8000, 0) + 15
> >  fe0dc229 __xnet_recvmsg (a, 80473f8, 0, fd110d4c, 0, 1) + 25
> >  fd110122 _xcb_in_read (81eab10, fe37, 80474c8, fe36239b) + 82
> >  fd110e71 xcb_poll_for_event (81eab10, 0, 0, feda5550, 0, 81ac380) + 91
> >  fd1c2ed5 poll_for_response (fd1c3a49, fd2b6000, 8047538, fd1ae469,
> > 8239780, fedcb840) + 135
> >  fd1c34cf _XEventsQueued (8239780, 2, fecf68fb, fed14000) + 5f
> >  fd1b2712 XPending (8239780, 8168910, fecff0d0, feda681b) + 62
> >  fe56c14a _ecore_x_fd_handler_buf (8239780, 816aad0, 80475b8, feda53d2)
> + 1a
> >  feda6854 _ecore_main_fd_handlers_buf_call (fed1469c, 3f, edb4,
> > 4005c842, fed1469c, 8047610) + 74
> >  feda8d6e ecore_main_loop_begin (feda9039, fedcb000, 8047648,
> > feda6114, 4102, 8168960) + ee
> >  feda9047 _efl_loop_begin

Re: [E-devel] Enlightenment on OpenIndiana

2016-10-24 Thread The Rasterman 
On Mon, 24 Oct 2016 17:30:09 +0200 Aurélien Larcher
 said:

> Hi,
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
> 
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
> 
> Again last week-end I updated our components
> 
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
> 
> and gave it a try... without success.
> 
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
> 
> If there is any interest, I would like to provide any debugging
> information that would help Enlightenment become a solid alternative
> to MATE on OpenIndiana.
> 
> As I am unfamiliar with the EFL codebase, I do not know which type of
> information would be suitable.
> Find below pstack outputs which may provide a starting point to an
> expert eye (in case similar issue has already been encountered with
> BSDs for instance).
> I can provide more debugging information, tests logs and give ssh
> access to a machine.

can you get a proper gdb backtrace of processes that hang. the below i THINK
is saying terminology is hanging in getpid(). ... no idea what pstack normally
says. elementary_Test is hung waiting for a reply from the xserver. thats what
it looks like.

both of these hangs would be fairly and squarely "an os/system issue on
solaris". getpid() hanging and never returning? that should NEVER happen. it's
just getting the current process id. the other - waiting on xserver. it
SHOULDNT even be talking tot he xserver. see the manual page on XPending:

   The XPending function returns the number of events that have been
   received from the X server but have not been removed from the event
   queue.  XPending is identical to XEventsQueued with the mode
   QueuedAfterFlush specified.

it really should very likely not be going and asking the xserver anything. we
want to know if any events are buffered/queued locally (already read from the
fd so the fd wont go active since the data is already out of the fd buffer and
into internal xlib buffers).

i don't know what to say... both of the traces i see smell to me like really
nasty OS issues at a glance. show me more info to say they are not, but this
would imply opensolaris is really badly broken. especially getpid() hanging.

> Kind regards
> 
> Aurelien
> 
> 
> helios> pstack `pgrep terminology`
> 12876:terminology
> -  lwp# 1 / thread# 1  
>  feeff915 getpid   (fafc, 400fa919, 8046118, fe9c8db9) + 15
>  fe9c8fef ecore_main_loop_begin (febf4409) + 36f
>  febf4417 elm_run  (0, 0, 752f0031, 81414f0, 40001415, 0) + 17
>  0806a559 elm_main (1, 804769c, 8047668, 806aa0d, 80bc000, 8047648) + e59
>  0806aa26 main (804765c, fef786e8, 8047690, 8062cb3, 1, 804769c) + 36
>  08062cb3 _start   (1, 80477fc, 0, 8047808, 8047824, 804782f) + 83
> -  lwp# 2 / thread# 2  
>  feefb5b9 lwp_park (0, 0, 0)
>  feef55f8 cond_wait_queue (fe698408, fe6983ec, 0, 1, 83088f8, 83088f8) + 6a
>  feef5c70 __cond_wait (fe698408, fe6983ec, fe657c9a, fe66b000,
> fef6e000, fe698408) + 8f
>  feef5cc4 cond_wait (fe698408, fe6983ec, fe50123b, fe5cf036, fe65965a,
> fe66b000) + 2e
>  feef5d0d pthread_cond_wait (fe698408, fe6983ec, fdb9ef98, fe5ced59) + 24
>  fe5cedde evas_thread_worker_func (0, 2, fdb9efc8, fedd1429, feed7c7e, 3) + 9e
>  fedd1432 _eina_internal_call (80bf5c0, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90240) + 88
>  feefb560 _lwp_start (fda90240, 0, 0, 0, 0, 0)
> -  lwp# 3 / thread# 3  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 4 / thread# 4  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 5 / thread# 5  
>  feefb5b9 lwp_park (0, 0, 0)
>  feeef15e sema_wait (81428d8, fef726c0, fd97ef28, feef41d9, fee0c000,
> 81428d8) + 19
>  feee22cd sem_wait (81428d8, fee10018, fda90a40, feef3e46) + 35
>  fedd24af eina_thread_queue_wait (8142898, fd97ef7c, fd97ef98, fe5c5c9c) + 3f
>  fe5c5cbf _evas_common_scale_sample_thread (0, 5, fd97efc8, fedd1429,
> feed7c7e, 3) + 3f
>  fedd1432 _eina_internal_call (8199d80, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90a40) + 88
>  feefb560

Re: [E-devel] Enlightenment on OpenIndiana

2016-10-24 Thread Simon Lees 


On 10/25/2016 02:00 AM, Aurélien Larcher wrote:
> Hi,
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
> 
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
> 
> Again last week-end I updated our components
> 
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
> 
> and gave it a try... without success.
> 
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
> 
All Linux distro's are building without xcb enabled as its actually
slower in this use case, but it seems like you are also building without
xcb as well which is correct. The rest of your configure flags for efl
also look sensible.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment on OpenIndiana

2016-10-24 Thread Cedric BAIL 
Hi !

On Mon, Oct 24, 2016 at 8:30 AM, Aurélien Larcher
 wrote:
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
>
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
>
> Again last week-end I updated our components
>
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
>
> and gave it a try... without success.
>
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
>
> If there is any interest, I would like to provide any debugging
> information that would help Enlightenment become a solid alternative
> to MATE on OpenIndiana.
>
> As I am unfamiliar with the EFL codebase, I do not know which type of
> information would be suitable.
> Find below pstack outputs which may provide a starting point to an
> expert eye (in case similar issue has already been encountered with
> BSDs for instance).
> I can provide more debugging information, tests logs and give ssh
> access to a machine.

I would recommend to do a git bisect in your case. Build efl manually
in 1.12 git branch, check that it still work. Then build efl from 1.16
branch and see if it broken. If it is, you can then start with a git
bisect. It should pin point you to the commit that borked things for
you. Be aware, that for every step in the git bisect of efl, you have
to recompile elementary on the same day/time more or less as the
commit in efl that you are testing. It is going to be very painful do
to .eo file syntax changing all the time, so you may have to go back
and forth, maybe skip some commit. Sadly it is likely going to be
still the easiest way to figure out what went wrong.

Cheers,
-- 
Cedric BAIL

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment on OpenIndiana

2016-10-24 Thread Daniel McLellan 
I actually got this to build some time ago on OI, and I recall that here
were issues with the preprocessor and comments.   Not sure if this helps.

On Mon, Oct 24, 2016 at 11:30 AM, Aurélien Larcher <
aurelien.larc...@gmail.com> wrote:

> Hi,
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
>
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
>
> Again last week-end I updated our components
>
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
>
> and gave it a try... without success.
>
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
>
> If there is any interest, I would like to provide any debugging
> information that would help Enlightenment become a solid alternative
> to MATE on OpenIndiana.
>
> As I am unfamiliar with the EFL codebase, I do not know which type of
> information would be suitable.
> Find below pstack outputs which may provide a starting point to an
> expert eye (in case similar issue has already been encountered with
> BSDs for instance).
> I can provide more debugging information, tests logs and give ssh
> access to a machine.
>
> Kind regards
>
> Aurelien
>
> 
> 
> helios> pstack `pgrep terminology`
> 12876:terminology
> -  lwp# 1 / thread# 1  
>  feeff915 getpid   (fafc, 400fa919, 8046118, fe9c8db9) + 15
>  fe9c8fef ecore_main_loop_begin (febf4409) + 36f
>  febf4417 elm_run  (0, 0, 752f0031, 81414f0, 40001415, 0) + 17
>  0806a559 elm_main (1, 804769c, 8047668, 806aa0d, 80bc000, 8047648) + e59
>  0806aa26 main (804765c, fef786e8, 8047690, 8062cb3, 1, 804769c) + 36
>  08062cb3 _start   (1, 80477fc, 0, 8047808, 8047824, 804782f) + 83
> -  lwp# 2 / thread# 2  
>  feefb5b9 lwp_park (0, 0, 0)
>  feef55f8 cond_wait_queue (fe698408, fe6983ec, 0, 1, 83088f8, 83088f8) + 6a
>  feef5c70 __cond_wait (fe698408, fe6983ec, fe657c9a, fe66b000,
> fef6e000, fe698408) + 8f
>  feef5cc4 cond_wait (fe698408, fe6983ec, fe50123b, fe5cf036, fe65965a,
> fe66b000) + 2e
>  feef5d0d pthread_cond_wait (fe698408, fe6983ec, fdb9ef98, fe5ced59) + 24
>  fe5cedde evas_thread_worker_func (0, 2, fdb9efc8, fedd1429, feed7c7e, 3)
> + 9e
>  fedd1432 _eina_internal_call (80bf5c0, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90240) + 88
>  feefb560 _lwp_start (fda90240, 0, 0, 0, 0, 0)
> -  lwp# 3 / thread# 3  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 4 / thread# 4  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 5 / thread# 5  
>  feefb5b9 lwp_park (0, 0, 0)
>  feeef15e sema_wait (81428d8, fef726c0, fd97ef28, feef41d9, fee0c000,
> 81428d8) + 19
>  feee22cd sem_wait (81428d8, fee10018, fda90a40, feef3e46) + 35
>  fedd24af eina_thread_queue_wait (8142898, fd97ef7c, fd97ef98, fe5c5c9c) +
> 3f
>  fe5c5cbf _evas_common_scale_sample_thread (0, 5, fd97efc8, fedd1429,
> feed7c7e, 3) + 3f
>  fedd1432 _eina_internal_call (8199d80, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90a40) + 88
>  feefb560 _lwp_start (fda90a40, 0, 0, 0, 0, 0)
> -  lwp# 6 / thread# 6  
>  feeffcc5 pollsys  (fb87fc30, 1, fb87fd68, 0)
>  fee9730f pselect  (13, fb87fde0, fb87fe60, fb87fee0, fb87fd68, 0) + 1bf
>  fee97618 select   (13, fb87fde0, fb87fe60, fb87fee0, fb87fdd8, 41197acd)
> + 8e
>  fe9bde8f _timer_tick_core (0, 83a7f10, fb87ff98, fe9cf948, fee0c000,
> 813a988) + 15f
>  fe9cf96c _ecore_direct_worker (83a7f10, 6, fb87ffc8, fedd1429,
> feed7c7e, 3) + 3c
>  fedd1432 _eina_internal_call (813a988, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda91a40) + 88
>  feefb560 _lwp_start (fda91a40, 0, 0, 0, 0, 0)
>
> 
> 
> helios> pstack 9171
> 9171:elementary_test
> -  lwp# 1 / thread# 1  
>  feeff475 __so_recvmsg (a, 80473f8, 8000, 0) + 15
>  fe0dc229 __xnet_recvmsg (a, 80473f8, 0, fd110d4c, 0, 1) + 25
>  fd110122 _xcb_in_read (81eab10, fe37, 80474c8, fe36239b) + 82
>  fd110e71 xcb_poll_for_event (81eab10, 0, 0, feda5550, 0, 81ac380) + 91
>  fd1c2ed5 poll_for_response (fd1c3a49, fd2b6000, 8047538, fd1ae469,
>