Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

GLib-ERROR **: Creating pipes for GWakeup: Too many open files #634

Closed
yock opened this issue Mar 6, 2018 · 8 comments
Closed

GLib-ERROR **: Creating pipes for GWakeup: Too many open files #634

yock opened this issue Mar 6, 2018 · 8 comments

Comments

@yock
Copy link

yock commented Mar 6, 2018

Albert v0.14.15 is crashing on Ubuntu 17.10 under the default Gnome 3 shell, installed via the official apt source hosted on opensuse.org. I ran it from a terminal window so I could see if it produced any errors when it crashed and I see the following:

(albert:25808): GLib-ERROR **: Creating pipes for GWakeup: Too many open files

zsh: trace trap (core dumped)  albert

It seems to happen after waking my laptop from sleep.
@ManuelSchneid3r
Copy link
Member

ManuelSchneid3r commented Mar 7, 2018 •
edited 

cat /proc/sys/fs/file-max
ulimit -Hn
ulimit -Sn
sysctl fs.inotify
ls -la  /proc/$(pidof albert)/fd | wc -l

please.

Maybe you should setup watch -n1 ls -la /proc/$(pidof albert)/fd and check it periodically. Post it if it is huge.

Do you use the Coinmarketcap extension?

@Talv
Copy link

Talv commented Mar 7, 2018 •
edited

Experiencing the same, since upgrade of albert (upgraded albert (0.12.0-1 -> 0.14.15-1)). Whenever I leave my PC idle on lockscreen for few hours, then come back I notice albert process has died.

dmesg

[59907.006303] traps: albert[17049] trap int3 ip:7f5fda08e982 sp:7f5cd3c6eb00 error:0 in libglib-2.0.so.0.5400.3[7f5fda03e000+113000]

albert output

[New Thread 0x7ffceb46e700 (LWP 14841)]

(albert:29595): GLib-ERROR **: Creating pipes for GWakeup: Too many open files


Thread 1041 "albert" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7ffceb46e700 (LWP 14841)]
0x00007ffff1f27982 in ?? () from /usr/lib/libglib-2.0.so.0

stack trace

(gdb) bt
#0  0x00007ffff1f27982 in  () at /usr/lib/libglib-2.0.so.0
#1  0x00007ffff1f28a2d in g_log_default_handler () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff1f28ccf in g_logv () at /usr/lib/libglib-2.0.so.0
#3  0x00007ffff1f28e50 in g_log () at /usr/lib/libglib-2.0.so.0
#4  0x00007ffff1f67723 in  () at /usr/lib/libglib-2.0.so.0
#5  0x00007ffff1f1f589 in g_main_context_new () at /usr/lib/libglib-2.0.so.0
#6  0x00007ffff4e1cc6c in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate(_GMainContext*) () at /usr/lib/libQt5Core.so.5
#7  0x00007ffff4e1cd43 in QEventDispatcherGlib::QEventDispatcherGlib(QObject*) () at /usr/lib/libQt5Core.so.5
#8  0x00007ffff4bd1b2b in  () at /usr/lib/libQt5Core.so.5
#9  0x00007ffff4bd2ba0 in  () at /usr/lib/libQt5Core.so.5
#10 0x00007ffff490c08c in start_thread () at /usr/lib/libpthread.so.0
#11 0x00007ffff6f58e7f in clone () at /usr/lib/libc.so.6

▶ cat /proc/sys/fs/file-max
1608564

▶ ulimit -Hn
4096

▶ ulimit -Sn
1024

▶ sysctl fs.inotify
fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 524288

▶ ls -la  /proc/$(pidof albert)/fd | wc -l
1027

▶ ls -l /proc/$(pidof albert)/fd | wc -l
1025

So apparently it exceeded limit of 1024 open files?
I did take a look at what these files were under fd, and at least 1k of these entries is stuff like:

lrwx------ 1 kk kk 64 03-07 13:45 1020 -> 'anon_inode:[eventfd]'
lrwx------ 1 kk kk 64 03-07 13:45 1021 -> 'anon_inode:[eventfd]'
lrwx------ 1 kk kk 64 03-07 13:45 1022 -> 'anon_inode:[eventfd]'
lrwx------ 1 kk kk 64 03-07 13:45 1023 -> 'anon_inode:[eventfd]'

etc.

What is that anon_inode:[eventfd]'?

@ManuelSchneid3r
Copy link
Member

What is that anon_inode:[eventfd]'?

I have absolutely no clue. Do you use the QML or widget frontend?

@Talv
Copy link

Talv commented Mar 7, 2018 •
edited

I'm using widget frontend, here's my config.
Also it includes log, I've noticed that Albert regularly spawns 10 threads (or more), and then only 8 of them exit. It appears anon_inode:[eventfd] correlates to these threads?

@ManuelSchneid3r
Copy link
Member

Okay thats important to know, because I had the impression that the QML frontend opens these fds. Further I realized that even disabling all extensions seems to bear this problem.

@Talv
Copy link

Talv commented Mar 7, 2018

Albert is definitely leaking threads. Number of open files is slowly increasing and for every thread there's anon_inode:[eventfd] entry within Albert's fd.
I'm at 74 already:

▶ ls -la  /proc/$(pidof albert)/fd | wc -l
74

Perhaps it has something to do with these Python extensions I recently enabled. Will try without them.

@Talv
Copy link

Talv commented Mar 7, 2018 

(gdb) info threads
  Id   Target Id         Frame 
* 1    Thread 0x7ffff7f96c80 (LWP 15853) "albert" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  2    Thread 0x7fffea5a9700 (LWP 15857) "QXcbEventReader" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  3    Thread 0x7fffdf176700 (LWP 15858) "Qt bearer threa" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  4    Thread 0x7fffde733700 (LWP 15859) "QDBusConnection" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  6    Thread 0x7fffc8972700 (LWP 15861) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  14   Thread 0x7fffdd696700 (LWP 16852) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  15   Thread 0x7fffc0b95700 (LWP 17066) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  16   Thread 0x7fffb37fe700 (LWP 17197) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  25   Thread 0x7fffab702700 (LWP 18706) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  26   Thread 0x7fffb17fa700 (LWP 19656) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  27   Thread 0x7fffb0ff9700 (LWP 20209) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  36   Thread 0x7fffc1b97700 (LWP 20927) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  37   Thread 0x7fffb2ffd700 (LWP 21128) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  38   Thread 0x7fffb3fff700 (LWP 21338) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  39   Thread 0x7fffaa700700 (LWP 21584) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  40   Thread 0x7fffc1396700 (LWP 21690) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  41   Thread 0x7fffb27fc700 (LWP 21804) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  42   Thread 0x7fffb1ffb700 (LWP 22062) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  43   Thread 0x7fffaaf01700 (LWP 22194) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  44   Thread 0x7fffa9eff700 (LWP 22303) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  45   Thread 0x7fffa96fe700 (LWP 22414) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  46   Thread 0x7fffa8efd700 (LWP 22517) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  47   Thread 0x7fff7bfff700 (LWP 22626) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  48   Thread 0x7fff7b7fe700 (LWP 22736) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  49   Thread 0x7fff7affd700 (LWP 22844) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  50   Thread 0x7fff7a7fc700 (LWP 23023) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  51   Thread 0x7fff79ffb700 (LWP 23306) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  52   Thread 0x7fff797fa700 (LWP 23501) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  53   Thread 0x7fff78ff9700 (LWP 23619) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  54   Thread 0x7fff57fff700 (LWP 23993) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  55   Thread 0x7fff577fe700 (LWP 24231) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  56   Thread 0x7fff56ffd700 (LWP 24512) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  57   Thread 0x7fff567fc700 (LWP 24697) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  58   Thread 0x7fff55ffb700 (LWP 24860) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6
  67   Thread 0x7fff3cff9700 (LWP 25064) "QNetworkAccessM" 0x00007ffff6f4e97b in poll () from /usr/lib/libc.so.6

@ManuelSchneid3r
Copy link
Member

ManuelSchneid3r commented Mar 7, 2018 •
edited

Yes indeed I found the resource leak. Thank you. This is a high prio issue. Will be released asap, i.e. probably next week.

ManuelSchneid3r added a commit that referenced this issue Mar 9, 2018
@ManuelSchneid3r
Fix resource leak. Closes #634
a770502
@ghost ghost mentioned this issue Jun 26, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@yock @ManuelSchneid3r @Talv