Welcome to awesome bug tracking system.

FS#940 - Freezes / pauses for 6 - 7 seconds when switching between tags

Attached to Project: awesome
Opened by Shankar (shankargopal) - Friday, 25 November 2011, 15:39 GMT
Task Type Bug Report
Category Tags
Status Unconfirmed
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version 3.4.10
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


I use awesome extensively, and thanks for all your work in making such a wonderful WM. There is only one strange behaviour that I have noticed recently. When switching between tags, I sometimes experience a random delay - usually about 5 seconds - before the switch happens. The delay is long enough that in that period I end up pressing the keybinding for switching several times, which then all occurs in a rush. Since I switched to awesome mainly for responsiveness, this is annoying.

I think, though I have not been able to confirm this (as it does not always happen), that the delay primarily occurs when certain applications are open. Emacs and the terminal (urxvt in my case) seem to be the main problems. But, as I said, this is only an impression.

I am attaching my rc.lua file.

Thanks a lot!
   rc.lua (18.5 KiB)
This task depends upon

Comment by Uli Schlachter (psychon) - Friday, 25 November 2011, 16:18 GMT
No idea what would cause those hangs. How easily can you reproduce this? Do you know "if I do this, that and this, then awesome will definitely hang"?

If you want to know exactly what awesome is doing during those hangs, install strace and run 'strace -tTp $(pidof awesome)' and attach the result (I do want to know).
Comment by Arvydas Sidorenko (Asido) - Friday, 25 November 2011, 18:43 GMT
I experience that once in a while too, but I noticed that it happened when I was on a poor wifi connection. Couples of times my PC totally freezed when it got disconnected and was like this until it got back to the network. I thought it's networkmanager problem. I switched to netcfg, but that didn't solve the problem totally. I still experience that one or two times in a day for ~3s. And it's not only when I start switching the tabs. It does happens when I am doing something in virtual guest, when browsing web or whatever. Couple of months ago I switched from slackware to archlinux and having this issue since then. Never ever had in slack.
Comment by anrxc (anrxc) - Saturday, 26 November 2011, 04:14 GMT
Guys are you using widgets accessing network resources? If they timeout they will block awesome. In vicious (in case you are using it) all timeouts are set to a maximum of 3 seconds for the full connection, with just 1 second given to the server to respond. It's not ideal, but it's a balance between having mostly emtpy widgets, and mostly populated... with such unfortunate side effects of blocking awesome for 1-3 seconds.
Comment by Arvydas Sidorenko (Asido) - Saturday, 26 November 2011, 06:08 GMT
I do use vicious, related to network 'net' and 'gmail' widgets. But that sounds strange to me since in arch I am currently using identical awesome configuration and version I used in slackware and never had experienced this behaviour.
Comment by Shankar (shankargopal) - Saturday, 26 November 2011, 06:18 GMT
Sorry, I don't actually know when it happens - it seems random, excpet that, as I said, it seems to occur more when the window being shown belongs to emacs or a terminal (this is just an impression). I've installed strace and started running it and will let you know what it says. In relation to the other comments, I have only one widget which is connected to a script that checks in with a local mail server. That script may occasionally lock for two or three seconds while getting the data. Might that be the problem? I'll watch it the next time the hang happens.
Comment by Shankar (shankargopal) - Saturday, 26 November 2011, 09:19 GMT
In the past few hours I experienced this problem twice (more rarely than usual). I am attaching the strace output from one incident (the other is too large to attach, and I also accidentally deleted it :( ). I stopped the trace immediately after the hang, so the relevant info should be near the end.
   trace.txt (3.08 MiB)
Comment by Uli Schlachter (psychon) - Saturday, 26 November 2011, 09:32 GMT
Here comes the magic:

$ awk '{ if (ex != $1) print last; last=$0; ex=$1 }' index.php\?getfile\=459 | grep -v epoll_wait
11:46:26 stat64("/usr/share/awesome/themes/zenburn/taglist/squarez.png", {st_mode=S_IFREG|0644, st_size=171, ...}) = 0 <0.000016>
11:46:47 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.087428>
11:47:24 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.087750>
11:48:01 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.088570>
11:48:38 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.761152>
11:49:15 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.081368>
11:49:23 read(5, "\1\10\r\222\3\0\0\0\37\0\0\0\0\0\0\0\f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 44 <0.000018>
11:49:52 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.083802>
11:50:29 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.085064>
11:51:06 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.080929>
11:51:43 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.749368>
11:52:20 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.088133>
11:52:57 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.097058>
11:53:30 stat64("/usr/share/awesome/themes/zenburn/taglist/squarez.png", {st_mode=S_IFREG|0644, st_size=171, ...}) = 0 <0.001317>
11:53:34 read(8, "Mail: 40255 KB\n", 4096) = 15 <2.082313>

You are using a script which produces the output "Mail: 40255 KB" and that script takes a little more than two seconds to run (that's the number at the end of the line). This is the only slow thing that I could find in there.
So I guess that means that your local mail server is too slow. However, there was no 5 second lag in that trace file.
Comment by Shankar (shankargopal) - Saturday, 26 November 2011, 09:48 GMT
You're probably right. I'll try to generate another trace to capture one of the longer hangs, but that could also be a result of this. Thanks a lot for this. Is there any way to make a widget load asynchronously (perhaps using awesome_client?) or should I just drop this particular widget?
Comment by Gregor Best (farhaven) - Saturday, 26 November 2011, 10:49 GMT
Yes. Just don't use a function in your rc.lua to populate the widget but instead have your script call something like 'echo mywidget:set_text("foo") | awesome-client', if you're using the git version of awesome or 'echo mywidget.text = "foo" | awesome-client' when it's done gathering data.
Comment by Arvydas Sidorenko (Asido) - Saturday, 26 November 2011, 18:16 GMT
I run strace for couple of hours until I recieved the freeze. This is what the filtering showed me:

$ awk '{ if (ex != $1) print last; last=$0; ex=$1 }' awesome.strace | grep -v epoll_wait
18:57:57 stat64("/usr/share/awesome/themes/arch/taglist/squarew.png", {st_mode=S_IFREG|0644, st_size=193, ...}) = 0 <0.000034>
18:58:07 read(8, "<?xml version=\"1.0\" encoding=\"UT"..., 4096) = 375 <0.885784>
19:01:08 writev(5, [{"\225\34\v\0\23\0@\0", 8}, {"\"\"\2\0\0\0\0\0\273\231\371\376\0\0\0\0\"\"\2\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 36}], 2) = 44 <0.000078>
19:03:07 read(8, "", 4096) = 0 <10.040754>
19:03:34 stat64("/usr/share/awesome/themes/arch/taglist/squarew.png", {st_mode=S_IFREG|0644, st_size=193, ...}) = 0 <0.000034>
19:03:39 writev(5, [{"\2\0\4\0\6\0`\2\10\0\0\0l]S\0*\2\3\0\6\0`\2M\315\336\0", 28}], 1) = 28 <0.000175>

Doesn't look very informative...
But either way, will try to disable my mail widget.
Comment by Uli Schlachter (psychon) - Saturday, 26 November 2011, 22:08 GMT
19:03:07 read(8, "", 4096) = 0 <10.040754>

That one looks way too slow, could you attach the log file's content from 19:02:00 to 19:03:07? (if you still have it)
Could your mail script fail to get any usable data? Would it produce no output in that case? Does it have a 10 second timeout?
(All the other lines are quite fast, so they seem ignoreable (minus the xml output which took a second, what's that?))
Comment by Arvydas Sidorenko (Asido) - Sunday, 27 November 2011, 15:10 GMT
I attached the file for your requested period.

I disabled my vicious gmail widget and no freezes since then. I am not sure in what way it can fail since it's all simple there - it just `curl` the gmail and matches some regexp on it. The xml is part of gmail widget. Every xml read follows that read(8, "", 4096), gmail response is in xml format:
<?xml version="1.0" encoding="UTF-8"?>
<feed version="0.3" xmlns="">
<title>Gmail - Inbox for</title>
<tagline>New messages in your Gmail Inbox</tagline>

I did another strace for couple of hours without gmail widget and the awk gave 0 results on it.
What actually suprises me is that I copy pasted my awesome config which I used on slackware 13.1 and 13.37 for a long time and never had this issue. So is it `curl` flaw here?