Firefox not able to terminate correctly (FUTEX_WAIT_PRIVATE)

Bug #400088 reported by Sean Hunt on 2009-07-16
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
firefox-3.0 (Ubuntu)
firefox-3.5 (Ubuntu)

Bug Description

Binary package hint: firefox-3.5

Using the jaunty firefox-3.5 package on a 9.04 system, version 3.5+nobinonly-0ubuntu0.9.04.1. When Fire^H^H^H^HShiretoko (why is that anyways? this is the release version) is closed, the process doesn't terminate. It will continue indefinitely (has been tested to run for hours). In order to start another instance of Shiretoko, you have to first kill the original process and start another, or else you will get an error about Shiretoko not responding.

Micah Gersten (micahg) wrote :

Thank you for reporting this to Ubuntu. Is your home directory on an NFS mount?

Changed in firefox-3.5 (Ubuntu):
status: New → Incomplete
Sean Hunt (coppro) wrote :

It's an ext4 mount. I forgot to mention it does this in safe mode with all extensions off; I forget what happened in other safe modes. I'll try them later.

Download full text (6.6 KiB)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20090718 Shiretoko/3.5.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20090718 Shiretoko/3.5.1

Since 3.5 i have the problem that Firefox is not able to terminate correctly. I disabled all plugins, and started using a blank Profile (in safe mode) nothing helped.

Distribution: arch
Filesystem: /dev/sda3 on / type ext4 (rw)

Reproducible: Always

Steps to Reproduce:
1. Start Firefox
2. Close Firefox (CTRL-Q, or menu)
3. Window disappears, process will not be closed.
Actual Results:
Window disappears, process will not be closed. So I have to kill the process manually to restart the browser (kill PID).

Expected Results:
Process terminates correctly.

# strace -ffff -s 256 firefox

unlink("/home/andy/.mozilla/firefox/aowqj2iz.default/lock") = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"\231\7\2\0f\0 \0046\0\2\0e\0 \4\231\7\2\0b\0 \0046\1\2\0a\0 \4\231\7\2\0~\0 \0046\0\2\0}\0 \4\231\7\2\0\355\0 \4\231\7\2\0q\1 \0046\0\2\0\354\0 \4\231\7\2\0\221\0 \0046\1\2\0\220\0 \4\231\7\2\0\275\0 \4\231\7\2\0r\1 \0046\1\2\0\274\0 \4\231\7\2\0j\0 \0046\6\2\0i\0 \4\231\7\2\0]\0 \0046\1\2\0\\\0 \4\231\7\2\0\271\0 \0046\0\2\0\270\0 \4\231\7\2\0\215\0 \0046\0\2\0\214\0 \4\231\7\2\0\305\0 \4\231\7\2\0\207\2 \0046\0\2\0\304\0 \4\231\7\2\0\245\0 \0046\0\2\0\244\0 \4\231\7\2\0\235\0 \0046\0\2\0\234\0 \4\231\7\2\0\225\0 \4\231\7\2\0k\1 \0046\0\2\0\224\0 \4\231"..., 796}, {NULL, 0}, {""..., 0}], 3) = 796
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3, "\21\345\243\21\203\0 \4\203\0 \4\320\2\36\10\354\"\302\277\5\0\0\0\210\"\302\277z\25\t\10\34\237\243\21\203\0 \4k\1\0\0\6}V\0\1\0\0\0\240\230\302\n\230!\302\277\330X\t\10\34\2\243\21\203\0 \4\37\1\0\0\6}V\0\1:G\n\240\230\302\n\230!\302\277\320\2\36\10\34\2\243\21\203\0 \4\35\1\0\0\6}V\0\1l\24\v\240\230\302\n\230!\302\277\320\2\36\10\34\2\243\21\203\0 \4\362\0\0\0\6}V\0\1\n&\v\240\230\302\n\230!\302\277\320\2\36\10\34\2\243\21\203\0 \4\21\1\0\0\6}V\0\1\213\"\n\240\230\302\n\230!\302\277\320\2\36\10\34\2\243\21\203\0 \4T\1\0\0\6}V\0\1\210\233\t\240\230\302\n\230!\302\277\320\2\36\10\34\2\243\21\203\0 \4$\0\0\0\6}V\0\1\333\220\n\240\230\302\n\230!\302\277\320\2\36\10\34"..., 4096) = 512
read(3, 0xb788d058, 4096) = -1 EAGAIN (Resource temporarily unavailable)
shmdt(0xb2859000) = 0
munmap(0xb09ae000, 4527600) = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"\217\2\2\0003\0 \4\220\4\2\0\2\0 \4\220\4\2\0\3\0 \4<\1\2\0005\0 \4<\7\2\0002\0 \4\4\0\2\0\1\0 \4<\7\2\0\0\0 \4.\7\2\0\257\0 \4+\0\1\0"..., 68}, {NULL, 0}, {""..., 0}], 3) = 68
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3, "\21\"\252\21\1\0 \4\1\0 \4\353\215\24\10\320\2\36\10\1\0 \4H\"\302\277\301Q\23\10\34\237\252\21\1\0 \4\364\0\0\0\6}V\0\1\0\0\0\310\252\311\t\230!\302\277\330X\t\10\34\2\252\21\1\0 \4C\0\0\0\6}V\0\1dC\v\31...


Ouch, on the lsof you see the libflashplayer. I pasted the wrong lsof :-( I really started ff w/o libflash (moved /usr/lib/mozilla/plugins/ into /tmp and restarted).

Correct lsof:

andy ~ $ lsof | grep moz
firefox 11769 andy mem REG 8,3 32516 167375 /usr/lib/xulrunner-1.9.1/components/
firefox 11769 andy mem REG 8,3 815304 167340 /usr/lib/xulrunner-1.9.1/
firefox 11769 andy 18wW REG 8,3 0 170519 /home/andy/.mozilla/firefox/mbyzr8n2.default/.parentlock
firefox 11769 andy 23wW REG 8,3 0 170519 /home/andy/.mozilla/firefox/mbyzr8n2.default/.parentlock
firefox 11769 andy 48uw REG 8,3 2048 170550 /home/andy/.mozilla/firefox/mbyzr8n2.default/cookies.sqlite
firefox 11769 andy 60u REG 8,3 2576 170574 /home/andy/.mozilla/firefox/mbyzr8n2.default/cookies.sqlite-journal
firefox 11769 andy 61r DIR 8,3 4096 204878 /home/andy/.mozilla/firefox/mbyzr8n2.default

And some additional info:
andy ~ $ ls -al /usr/lib/mozilla/plugins/
insgesamt 8
drwxr-xr-x 2 root root 4096 19. Jul 23:41 .
drwxr-xr-x 3 root root 4096 25. Feb 00:27 ..
andy ~ $ killall firefox
andy ~ $ rm -rf .mozilla
andy ~ $ firefox -safe-mode

I have this same problem about half the time I close FF3.5, and am also running Ext4.

Disabling all extensions (renaming my directory so it starts clean even), does not make the problem go away. I'm not seeing this behavior with any other application.

Before killing the process, I've noticed that many times it appears to be using a lot of CPU.

Two Ubuntu users (myself included) have reported this bug on ext4 systems to Launchpad at My entire computer is ext4 on several partitions (/, /boot, /home, /usr). Safe mode does not alleviate the problem.

Additionally, when Firefox performs a restart (e.g. due to addons), it does this successfully and does not hang.

Micah Gersten (micahg) on 2009-07-20
Changed in firefox-3.5 (Ubuntu):
status: Incomplete → Confirmed
summary: - Firefox 3.5 doesn't terminate
+ Firefox 3.5 doesn't terminate with home dir on ext4

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at:

By the way, are either of you on an amd64 system?

Changed in firefox-3.5 (Ubuntu):
importance: Undecided → High
status: Confirmed → Triaged
Changed in firefox:
status: Unknown → New
Sean Hunt (coppro) wrote :

Nope, this is an x86.

clemens.kol (clemens-kol) wrote :

I can confirm this bug on an amd64 system.

BUT: my home directory is NOT mounted as ext4. It is on a seperate ext3 partition, with a symlink in my home directory.

I deleted the ~/.mozilla/firefox-3.5 directory, same problem... so no locking issue.

Might it be possible to try a standard firefox build, not one built by ubuntu, and see if this resolves the issue?

As opener I'm using archlinux NOT Ubuntu. Archlinux is strictly upstream. Thats why i opened a direct bug @ your bugzilla. Means archlinux does not selfpatch anything.

But i tried also the static build (the official one)

8b2975397f378e93d5808899efe2486b firefox-3.5.1.tar.bz2

Same effect.

Created an attachment (id=390072)
FF 3.5.1 (Official Static Build)

Strace of the "bottom" of an strace using the official build. Similar FUTEX problems....

I am running kubuntu 9.04 and after installing firefox-3.5 I experienced the same problem as well. But now even firefox-3.0.12 has the same issue (strace shows it stopping on exact same FUTEX_WAIT_PRIVATE).

I have /home on ext3. I tried deleting ~/.mozilla but it didnt remove the problem. It seems like Firefox is quitting normally sometimes, but most of the time the process hangs on the FUTEX_WAIT_PRIVATE.

I can confirm that this bug exists also with x86 + ext3 /home partition. In my case it is also present in firefox 3.0.12.

Deleting ~/.mozilla/ didn't change anything.


yes, could be that it's not an issue with the filesystem itself (i copied the official static build over to an vfat and also to an ext3, same problem).

So maybe something with glibc or kernel or CPU ? Threads ?

Btw, the other apps are ALL running normally (KDE, Opera, ClawsMail, etc...etc... _ONLY_ Firefox shows up this problem).

uname -a
2.6.30-ARCH #1 SMP PREEMPT Mon Jul 20 11:20:32 UTC 2009 i686 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux

My instance was on an amd64 system, and my home directory is using ecryptfs.

Like Sami, I too see the same behavior from FF3.0 (I didn't notice it before, because I generally only use 3.5).

Micah Gersten (micahg) on 2009-07-31
summary: - Firefox 3.5 doesn't terminate with home dir on ext4
+ Firefox not able to terminate correctly (FUTEX_WAIT_PRIVATE)
Changed in firefox-3.0 (Ubuntu):
importance: Undecided → High
status: New → Triaged


Hm... OK, seems to be KDE specific (or kwin, whatever). I installed XFCE with Slim as Loginmanager (because KDE made me angry in some points >:-( ). And I cant see/reproduce the problem anymore.

Firefox opens and closes w/o any problems.

@Sami: Try perhaps also to start with another environment. If you can solve it this way, I think it could be that this bug is not (just?) Firefox specific.

OR, it is solved in version 3.5.2 oO (i saw that im on 3.5.2 meanwhile).

So, it's either KDE/KWIN or the new 3.5.2 Version. But in either case: I cant reproduce it right now.

I am currently using 3.5.2 (ubuntu) and am having a problem that it hangs when i exit.

Using strace i get:
Process 5570 attached - interrupt to quit
futex(0x7f692aeaa0d0, FUTEX_WAIT_PRIVATE, 2, NULL) = ? ERESTARTSYS (To be restarted)
--- SIGTERM (Terminated) @ 0 (0) ---
rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [TERM], NULL, 8) = 0
tgkill(5570, 5570, SIGTERM) = 0
--- SIGTERM (Terminated) @ 0 (0) ---
Process 5570 detached

i'll see if i can try with another window manager.

Switching to xcfe4 and starting and shutting down firefox works without a problem.
But switching back to kde 4.3 it hangs when closing.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090824 Firefox/3.5.3

Same issue for me on Windows XP SP3 with Firefox 3.5.3.

Firefox doesn't terminate correctly. firefox.exe keeps running and I need to use the task manager > terminate process.

Reproducible 80-90% of times. Firefox seldom terminates ptoperly.

Jesse Sweetland (sweetlandj) wrote :

I had this problem every time I closed Shiretoko until I went into System Settings -> Appearance -> GTK Styles and Fonts and then clicked "Install Scrollbar Fix". After that everything seems to be working (Kubuntu 9.04)

I purged/re-installed firefox-3.5 yesterday, changed my theme, and haven't seen the issue since.

Jahava (danjacques) wrote :

At the moment this is anecdotal, but I have experienced this problem through the entire Firefox 3.0+ lines. Recently, I was addressing some KDE4 graphical glitches that occurred when using GTK applications:

System Settings -> Appearance -> GTK Styles and Fonts:
"GTK Styles": Usage another style: "QtCurve"
(Hit "Apply" and restart any GTK+ Applications, including Firefox; in the event of this bug, make SURE the process is terminated via 'ps/kill' as documented in previous comments)

After changing this, my rendering glitches in GTK applications running in KDE4 did stop, which was awesome. Firefox was one such application that was affected by this (being a GTK+ application).

However, I _also_ have noticed (so far) that all of the instances of the process not terminating when all of its windows were closed (i.e. this bug) have also stopped since making that change. I've even tried changing the setting back and immediately notice the familiar "process already running" messages reappearing.

Could someone else who is experiencing this using Kubuntu / KDE4 try making this change and see if your results coincide with mine?

FWIW, I've done the scrollbar fix a number of times with no result ... not to contradict you, Jesse, but rather to attempt to get a better understanding for this problem.

Same issue on Fedora 11 ( with Firefox 3.5.4 on KDE only.

Sheng Yang (yasker) wrote :

Confirm the "QtCurve" works like a charm!

John Vivirito (gnomefreak) wrote :

Sorry but Firefox-3.0 has reached EOL and will not receive anymore updates.

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Won't Fix
John Vivirito (gnomefreak) wrote :

It has been decided to release 3.0.18 as of the meeting yesterday

Changed in firefox-3.0 (Ubuntu):
status: Won't Fix → Triaged

Metoo. Firefox is

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2) Gecko/20100122 Firefox/3.6

built on Debian SID amd64.

I'm not experiencing this specific problem any more on Ubuntu Karmic, though I am experiencing hangs that appear related to plugins.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7

Qt: 4.5.2
KDE: 4.3.2 (KDE 4.3.2)
KWin: 4.3.2 (KDE 4.3.2)

zellfaze (zellfaze) wrote :

Not sure, but it might be related to bug #523979 They both seem to deal with Firefox hanging in Futex_wait. They also both seem to deal with Firefox requiring to be killed in order to fix.

I've been having the same problems as the rest of you. CentOS 5.3 and CentOS 5.4... I switched to Fedora Core 12 and am still experiencing this problem. All partitions are ext4 except for /home which is still ext3. I have run with FF 3.5 and FF 3.6 including nightly build versions with the same problem. I have run with the new KDE (yuk) AND then switched to KDE (yuk) experimental WITHOUT any change in behavior.

Do "we" know what is being locked by FF? Is it the same for all cases?

When I issue this command, "ps -efadlcL | grep firefox" I see the original FF and all threads running and another instance trying to start. The only way to resolve this conflict that I can see is to kill the owner of the threads. This will allow FF instance 2 to continue.

dianna (destiny-grl2002) wrote :


Changed in firefox-3.0 (Ubuntu):
status: Triaged → Fix Committed
Changed in firefox-3.5 (Ubuntu):
status: Triaged → Fix Committed
John Vivirito (gnomefreak) wrote :

Any reason you marked this as fix committed. I have not seen anyone say they committed a fix for this yet.
Changing back to triaged until someone can point me to the fix that has been committed

Changed in firefox-3.0 (Ubuntu):
status: Fix Committed → Won't Fix
Changed in firefox-3.5 (Ubuntu):
status: Fix Committed → Triaged
John Vivirito (gnomefreak) wrote :

Can anyone reproduce this bug using firefox-3.6 in Karmic or Lucid?

jervin (jervin) wrote :

It happens to me daily on my Ubuntu 10.04 system. I am running Firefox version 3.6.5pre but the problem has existed for me since at least ubuntu 9.10 and a few previous versions of Firefox. It doesn't happen every time, it seems to happen when Firefox has been left up for a while and multiple website have been visited, but then I guess the longer you have it up, the more chance you'll do the "thing" that causes it to hang on exit. Several times a day, when I exit Firefox, it doesn't terminate and when I check the Task Manager, it's using a lot of Processor and it never ends and as described before, you can't start another instance of Firefox until it's terminated/killed. I'm am not sure what the magic combination of things that causes it to not be able to be terminated. Also, it doesn't seem to be sucking processor prior to being terminated.

jervin (jervin) wrote :

Is there anything I can do to help with this problem? Firefox seems to go into that shutdown loop several times a day for me. I should be able to get some sort of dumps or whatever if you have any ideas that might help.

Changed in firefox:
importance: Unknown → Medium

Is problem gone with version 3.6 or 4.0 beta?
Bug 555912 - Firefox enters futex loop after crash - a duplicate? (zug is normally correct)

Sheng Yang (yasker) wrote :

At least I didn't meet this issue on 10.10. Maybe we can close it?

clemens.kol (clemens-kol) wrote :

Cannot remember seeing this bug in the last couple of months. Thumbs up for closing it! (y)

I can confirm this bug as still present (and still annoying). Running on gentoo x86 (ext3 fs, local), with firefox-3.6.13 and xulrunner- this still happens everytime i try to close firefox:

[pid 9921] gettimeofday({1294303284, 322229}, NULL) = 0
[pid 9921] futex(0x8151c00, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 9921] clock_gettime(CLOCK_REALTIME, {1294303284, 322291382}) = 0
[pid 9921] futex(0x8152848, FUTEX_WAIT_PRIVATE, 3999, {0, 999937618}) = -1 ETIMEDOUT (Connection timed out)
[pid 9921] gettimeofday({1294303285, 322390}, NULL) = 0
[pid 9921] futex(0x8151c00, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 9921] clock_gettime(CLOCK_REALTIME, {1294303285, 322450622}) = 0
[pid 9921] futex(0x8152848, FUTEX_WAIT_PRIVATE, 4001, {0, 999939378}) = -1 ETIMEDOUT (Connection timed out)

and repeating every 1 second.

Changed in firefox:
importance: Medium → Critical
status: New → Confirmed

Seeing this with Firefox 26 on openSUSE 13.1 x86_64, KDE 4.11.3 with an ext4 filesystem.

Ubuntu 13.04 x86_64; ext4; MATE DE
Package: firefox Version: 26.0+build2-0ubuntu0.13.04.2
Experiencing the same behavior, ff is unable to terminate correctly, leaving its' process that "eats" up to magical 300% of CPU time, until being killed manually.

Just saw this on Ubuntu 13.10 x86_64; ext4; MATE GB

||/ Name Version Architecture Description
ii firefox 30.0~b2+build1-0ubuntu0.13.1 amd64 Safe and easy web browser from Mozilla

$ sudo strace -p 3557 -f
Process 3557 attached with 23 threads
[pid 3664] futex(0x7ffad64f2e24, FUTEX_WAIT_PRIVATE, 7, NULL <unfinished ...>
[pid 3663] futex(0x7ffadd356ee4, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid 3659] futex(0x7ffaeb95e464, FUTEX_WAIT_PRIVATE, 7, NULL <unfinished ...>
[pid 3658] futex(0x7ffae799dc44, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid 3657] futex(0x7ffadd534b0c, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid 3635] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 3630] futex(0x7ffaf6ee0a3c, FUTEX_WAIT_PRIVATE, 63, NULL <unfinished ...>
[pid 3626] futex(0x7ffaf645d2dc, FUTEX_WAIT_PRIVATE, 57, NULL <unfinished ...>
[pid 3594] futex(0x7ffaf6ea835c, FUTEX_WAIT_PRIVATE, 41, NULL <unfinished ...>
[pid 3592] futex(0x7ffaf77ff56c, FUTEX_WAIT_PRIVATE, 319, NULL <unfinished ...>
[pid 3586] futex(0x7ffb2331490c, FUTEX_WAIT_PRIVATE, 11332, NULL <unfinished ...>
[pid 3585] futex(0x7ffb2331490c, FUTEX_WAIT_PRIVATE, 11333, NULL <unfinished ...>
[pid 3586] <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable)
[pid 3585] <... futex resumed> ) = -1 EAGAIN (Resource temporarily unavailable)
[pid 3586] futex(0x7ffb2331490c, FUTEX_WAIT_PRIVATE, 11334, NULL <unfinished ...>
[pid 3585] futex(0x7ffb2331490c, FUTEX_WAIT_PRIVATE, 11334, NULL <unfinished ...>
[pid 3584] futex(0x7ffb2331490c, FUTEX_WAIT_PRIVATE, 11334, NULL <unfinished ...>
[pid 3583] futex(0x7ffb2331490c, FUTEX_WAIT_PRIVATE, 11331, NULL) = -1 EAGAIN (Resource temporarily unavailable)
[pid 3570] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 3583] futex(0x7ffb2331490c, FUTEX_WAIT_PRIVATE, 11334, NULL <unfinished ...>
[pid 3569] restart_syscall(<... resuming interrupted call ...> <unfinished ...>
[pid 3568] futex(0x7ffb0f0aeb8c, FUTEX_WAIT_PRIVATE, 1, NULL <unfinished ...>
[pid 3567] futex(0x7ffb0e68844c, FUTEX_WAIT_PRIVATE, 689, NULL <unfinished ...>
[pid 3566] futex(0x7ffb0e68834c, FUTEX_WAIT_PRIVATE, 291, NULL <unfinished ...>
[pid 3564] epoll_wait(12, <unfinished ...>
[pid 3557] futex(0x7ffb233b414c, FUTEX_WAIT_PRIVATE, 11, NULL

I am experiencing the same problems since around FF 30 on Ubuntu 12.04 LTS and 14.04 LTS:

poll([{fd=9, events=POLLIN}], 1, -1) = 1 ([{fd=9, revents=POLLIN}])
recvfrom(9, "\1 \0279\4\0\0\0\6\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 0, NULL, NULL) = 48
recvfrom(9, 0x7ff898704074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7ff898704074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=9, revents=POLLOUT}])
writev(9, [{"\16\0\2\0\272\0\300\3", 8}, {NULL, 0}, {"", 0}], 3) = 8
poll([{fd=9, events=POLLIN}], 1, -1) = 1 ([{fd=9, revents=POLLIN}])
recvfrom(9, "\1\30\0309\0\0\0\0\272\2\0\0\0\0\0\0@\6\230\4\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0, NULL, NULL) = 32
recvfrom(9, 0x7ff898704074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7ff898704074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=9, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=9, revents=POLLOUT}])
writev(9, [{"(\0\4\0\272\0\300\3\272\2\0\0\0\0\0\0", 16}, {NULL, 0}, {"", 0}], 3) = 16
poll([{fd=9, events=POLLIN}], 1, -1) = 1 ([{fd=9, revents=POLLIN}])
recvfrom(9, "\1\1\0319\0\0\0\0n\273\301\0\220\6\30\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0, NULL, NULL) = 32
recvfrom(9, 0x7ff898704074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvfrom(9, 0x7ff898704074, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2309, ...}) = 0
futex(0x7ff88cf438a0, FUTEX_WAIT_PRIVATE, 2, NULL

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.