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.

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

Fix #626(Segmentation fault from xcffib when quitting) #658

Closed
wants to merge 1 commit into from

Conversation

@luxrck
Copy link
Contributor

luxrck commented Apr 5, 2015

Well...... This is worked for me......

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 12, 2015

Hi, does this not cause qtile to hang when it exits, since there is no way for the daemon thread to exit? The docs say:

The entire Python program exits when no alive non-daemon threads are left.
@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 13, 2015

MainThread will not wait daemon threads, and daemon threads will exits after MainThread exits. So...... I don't think we need to care about it. (Does it hangs in your computer ?)

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 13, 2015

And I think the problem is thread exit-order, not gobject_thread, mainly...dbus. I think if gobject_thread exits after mainthread then this bug will not happen. BTW:

#in Drawer.__del__
self.qtile.conn.conn.core.FreeGC(self.gc)
self.qtile.conn.conn.core.FreePixmap(self.pixmap)

does this will cause some dbus-related calls ?

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 13, 2015

Does that mean the documentation is wrong, then? Looking at the sentence from the docs I quoted, I would expect it to hang until all the threads exit. Does this fix it for you? tych0@d33b200

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

The doc is not wrong, main thread will wait all non-daemon threads but it won't wait for any daemon threads. And you could not just join the gobject thread because...... it hangs on my computer......

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 14, 2015

Oh whoops, I totally spaced the non-daemon bit, my apologies. @kynikos, since you can reproduce the issue, can you verify that the above fixes it for you too? Thanks!

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

Um... tl;dr it doesn't... ^^'
What I've done is:

  1. fetch and checkout your "fix-segfault" branch
  2. open a second tty
  3. run startx test_xinitrc with the minimal xinitrc as in #626 (comment)
  4. once X is started, cd into qtile's repo directory
  5. run ./bin/qtile -c test.conf with the minimal configuration from #626 (comment)
  6. once qtile is started, quit with "Super+Ctrl+q"
    This raises a segfault:
2015-04-14 20:39:12,755 qtile init_log:100  Starting Qtile
2015-04-14 20:39:14,149 qtile safe_import:49  Can't Import Widget: '.mpriswidget.Mpris', No module named 'dbus'
2015-04-14 20:39:14,152 qtile safe_import:49  Can't Import Widget: '.mpris2widget.Mpris2', No module named 'dbus'
2015-04-14 20:39:14,155 qtile safe_import:49  Can't Import Widget: '.mpdwidget.Mpd', No module named 'mpd'
2015-04-14 20:39:14,169 qtile safe_import:49  Can't Import Widget: '.wlan.Wlan', No module named 'pythonwifi'
2015-04-14 20:39:14,172 qtile safe_import:49  Can't Import Widget: '.google_calendar.GoogleCalendar', No module named 'httplib2'
2015-04-14 20:39:14,174 qtile safe_import:49  Can't Import Widget: '.imapwidget.ImapWidget', No module named 'keyring'
2015-04-14 20:39:14,178 qtile safe_import:49  Can't Import Widget: '.keyboardkbdd.KeyboardKbdd', No module named 'dbus'
2015-04-14 20:39:14,394 qtile setup_python_dbus:266  importing dbus/gobject failed, dbus will not work.
Exception ignored in: <bound method Drawer.__del__ of <libqtile.drawer.Drawer object at 0x7fabe084abe0>>
Traceback (most recent call last):
  File "/mnt/archive/Development/qtile/bin/libqtile/drawer.py", line 232, in __del__
  File "/usr/lib/python3.4/site-packages/xcffib/xproto.py", line 2052, in FreeGC
  File "/usr/lib/python3.4/site-packages/xcffib/__init__.py", line 355, in send_request
  File "/usr/lib/python3.4/site-packages/xcffib/__init__.py", line 518, in wrapper
  File "/usr/lib/python3.4/site-packages/xcffib/__init__.py", line 508, in invalid
xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Segmentation fault (core dumped)
  1. to get a backtrace I run gdb -ex r --args python ./bin/qtile -c test.conf, quit again and run bt in gdb's interface, which gives:
#0  0x00007ffff11f9c90 in ?? ()
#1  0x00007ffff20ee1f0 in ffi_call_unix64 () from /usr/lib/libffi.so.6
#2  0x00007ffff20edc58 in ffi_call () from /usr/lib/libffi.so.6
#3  0x00007ffff22fcfc2 in ?? () from /usr/lib/python3.4/site-packages/_cffi_backend.cpython-34m.so
#4  0x00007ffff79a9528 in PyObject_Call (func=func@entry=0x7fffeb319df0, arg=arg@entry=0x7ffff3ffc908, kw=kw@entry=0x0) at Objects/abstract.c:2040
#5  0x00007ffff7a5b4ea in do_call (nk=<optimized out>, na=<optimized out>, pp_stack=0x7fffffffdc50, func=<optimized out>) at Python/ceval.c:4466
#6  call_function (oparg=<optimized out>, pp_stack=0x7fffffffdc50) at Python/ceval.c:4264
#7  PyEval_EvalFrameEx (f=0x555555b57298, throwflag=<optimized out>) at Python/ceval.c:2838
#8  0x00007ffff7a5e947 in PyEval_EvalCodeEx (_co=0x555555d953f0, globals=0x1000100010001, locals=0x1000100010001, locals@entry=0x0, args=0x7ffff4010648, argcount=65537, kws=0x1000100010001, 
    kws@entry=0x0, kwcount=-349045616, defs=0x0, defcount=0, kwdefs=0x0, closure=0x7ffff2074860) at Python/ceval.c:3588
#9  0x00007ffff79d1ad9 in function_call (func=0x7fffec46e488, arg=0x7ffff4010630, kw=0x0) at Objects/funcobject.c:632
#10 0x00007ffff79a9528 in PyObject_Call (func=func@entry=0x7fffec46e488, arg=arg@entry=0x7ffff4010630, kw=kw@entry=0x0) at Objects/abstract.c:2040
#11 0x00007ffff79aa0bc in PyObject_CallFunctionObjArgs (callable=callable@entry=0x7fffec46e488) at Objects/abstract.c:2332
#12 0x00007ffff7a369b3 in handle_callback (ref=ref@entry=0x7ffff15177c8, callback=callback@entry=0x7fffec46e488) at Objects/weakrefobject.c:868
#13 0x00007ffff7a39930 in PyObject_ClearWeakRefs (object=<optimized out>) at Objects/weakrefobject.c:915
#14 0x00007ffff22f7720 in ?? () from /usr/lib/python3.4/site-packages/_cffi_backend.cpython-34m.so
#15 0x00007ffff79e1927 in dict_dealloc (mp=0x7ffff2073e48) at Objects/dictobject.c:1383
#16 0x00007ffff79fa9b4 in subtype_dealloc (self=0x7ffff16b4630) at Objects/typeobject.c:1186
#17 0x00007ffff79e1927 in dict_dealloc (mp=0x7ffff16d9c08) at Objects/dictobject.c:1383
#18 0x00007ffff79fa9b4 in subtype_dealloc (self=0x7ffff36b91d0) at Objects/typeobject.c:1186
#19 0x00007ffff79e1927 in dict_dealloc (mp=0x7fffeb30d508) at Objects/dictobject.c:1383
#20 0x00007ffff79fa402 in subtype_clear (self=0x7fffeb30c7f0) at Objects/typeobject.c:1047
#21 0x00007ffff7a94872 in delete_garbage (old=<optimized out>, collectable=<optimized out>) at Modules/gcmodule.c:866
#22 collect (generation=generation@entry=2, n_collected=n_collected@entry=0x0, n_uncollectable=n_uncollectable@entry=0x0, nofail=nofail@entry=1) at Modules/gcmodule.c:1032
#23 0x00007ffff7a954f1 in _PyGC_CollectNoFail () at Modules/gcmodule.c:1638
#24 0x00007ffff7a6fa99 in PyImport_Cleanup () at Python/import.c:483
#25 0x00007ffff7a7bf54 in Py_Finalize () at Python/pythonrun.c:616
#26 0x00007ffff7a93404 in Py_Main (argc=0, argv=0x0) at Modules/main.c:771
#27 0x0000555555554c06 in main ()

At this stage, maybe you could try to do the same and see if you can reproduce it, otherwise maybe it's something on my system...

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

PS, using the default header commands from /etx/X11/xinit/xinitrc doesn't change the result.

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

What ?

$ Xephyr -ac -br -noreset -screen 800x600 :1
$ DISPLAY=:1.0 qtile -c test.py

does this works ? BTW, could you upgrade xcffib to 0.2.2

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

I use archlinux, too. but I can't reproduce it. my sysinfo:

xorg-server: 1.17.1
python-xcffib: 0.2.2
xorg-xinit(startx): 1.3.4
dbus: 1.8.16
python-dbus: 1.2.0
@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

Hi @kynikos are you still get segfault ?

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

I have exactly the same sysinfo. As I said, I segfault only with the above procedure.
Do you always install qtile system-wide for testing it, or do you just run the executable in the bin directory like I do?

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

I run from source bin directory, too. ...... This is wired.

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

But... reading your command above DISPLAY=:1.0 qtile -c test.py it looked like you were running a system-wide command... Can you post the exact procedure that you're using for testing, like I've done with mine?

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

export PATH=$PATH:~/src/qtile/bin
alias xnest="Xephyr -ac -br -noreset -screen 800x600 :1"
xnest &
DISPLAY=:1.0 qtile -c test.py
@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

What config do you use? How exactly do you quit the qtile in Xephyr to test this bug?

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

I use your config file

from libqtile.config import Key, Screen, Group, Drag, Click
from libqtile.command import lazy
from libqtile import layout, bar, widget, hook

keys = [Key(["mod4", "control"], "q", lazy.shutdown())]
groups = [Group("a")]
layouts = [layout.Max()]
screens = [Screen(
    bottom=bar.Bar([], 32),
)] 

and of course Ctrl-Meta-q to quit.

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

I see, I can't really get the qtile in Xephyr to quit with Ctrl-Meta-q or any other combination, I don't know what we're doing different... Meanwhile have you tried my procedure instead?

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

@kartoch Sorry, my fault. Super+Ctrl+q to quit. I always consider that 'windows' key as meta key. ><!!!

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

No worries, it's just that I can't make the qtile in Xephyr get my keyboard shortcuts... However I can quit qtile with DISPLAY=:1.0 qsh and then issuing shutdown(): this still raises the exception I reported in #658 (comment) but without the segfault. Note that, as I said in #626, commenting the bottom=bar.Bar([], 32), line changes the behavior, in this case avoiding the exception but outputting Exception ignored in: without anything after that... All this is still in @tych0's "fix-sefgault" branch.

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

you fetch from tych0's 'fix-segfault' branch? I saw it just now, that is not my code. please use my branch i626. >_<!!!

luxrck@e80de1a

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 14, 2015

Uh sorry, I misinterpreted what tych0 meant with "the above" in #658 (comment)
Ok, luxrck@e80de1a prevents the segfault in your test procedure, but still outputting that weird Exception ignored in: at the end.
With my testing procedure, the exception and the segfault are still there unfortunately...
(Now I've also run out of time here, I'll be back in half a day or so I guess)

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 14, 2015

Thanks for your reply !

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 15, 2015

I'm back with a possibly useful hint: kynikos@db70c59 fixes the bug for me, does anyone know what that destructor is doing exactly, and why it segfaults?

@luxrck

This comment has been minimized.

Copy link
Contributor Author

luxrck commented Apr 15, 2015

Hi @kynikos , what's your irc nick name on irc://irc.oftc.net:6667/qtile ?

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 15, 2015

I'm in as kynikos now

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 15, 2015

@tych0 we fixed it in IRC, the patch works for me too, I was missing a new dependency on my system ^^'

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 15, 2015

Hi, sorry, what's the final verdict? Does the patch in this PR fix it?

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 15, 2015

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 15, 2015

So you've been able to reproduce this crash without gobject installed? Installing gobject certainly shouldn't fix it. Actually, I think after talking through this I may understand what's going on here...

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 15, 2015

Yes, to avoid segfaults I have to have 1) python-gobject and 2) python-dbus installed, plus 3) @luxrck's patch: if any of these 3 elements is missing, a segfault is raised when quitting for me in the testing scenario I described above.

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 15, 2015

How about this instead? tych0@aff959d

(if that doens't work, I promise I'll try to find some time to reproduce it myself :)

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 15, 2015

Sorry, still same exception with segfault... (tested with python-{dbus,gobject} installed)

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 15, 2015

Ok, hmm. I don't think this patch is right, though, I'd say it just causes the race to go favorably if gobject happens to be installed. I'd really like to know what's going on vs. just merging a bandaid, though.

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 15, 2015

Of course, if you think this is a band-aid it's better if we investigate it better and find the real cause of the race: take your time and ask any more info/help you will need! After all, this bug is not creating any problems in practice, so there's no hurry ;)

@tych0

This comment has been minimized.

Copy link
Member

tych0 commented Apr 22, 2015

On Wed, Apr 15, 2015 at 08:56:04AM -0700, Dario Giovannetti wrote:

Of course, if you think this is a band-aid it's better if we investigate it better and find the real cause of the race: take your time and ask any more info/help you will need! After all, this bug is not creating any problems in practice, so there's no hurry ;)

I have another 15 hours or so on planes coming this weekend, so I hope
to investigate more then :)


Reply to this email directly or view it on GitHub:
#658 (comment)

@w1ndy

This comment has been minimized.

Copy link
Contributor

w1ndy commented Apr 23, 2015

hi @kynikos , you may try w1ndy/qtile@4932f4f and see if segfault still there

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 25, 2015

Hey w1ndy, I'm sorry, your branch is still segfaulting... On the other hand, it prevents the following exception that is instead occurring in the current develop branch (a51189a), before the segfault:

Exception ignored in: <bound method Drawer.__del__ of <libqtile.drawer.Drawer object at 0x7ff5e8d73358>>
Traceback (most recent call last):
  File "/mnt/archive/Development/qtile/bin/libqtile/drawer.py", line 232, in __del__
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
...
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
  File "/usr/lib/python3.4/site-packages/xcffib/xproto.py", line 2052, in FreeGC
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
...
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
  File "/usr/lib/python3.4/site-packages/xcffib/__init__.py", line 355, in send_request
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
...
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
  File "/usr/lib/python3.4/site-packages/xcffib/__init__.py", line 518, in wrapper
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
...
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
  File "/usr/lib/python3.4/site-packages/xcffib/__init__.py", line 508, in invalid
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
...
/usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty
xcffib.ConnectionException: xcb connection errors because of socket, pipe and other stream errors.
Segmentation fault (core dumped)

The ellipses represent many repeated /usr/lib/python3.4/importlib/_bootstrap.py:2150: ImportWarning: sys.meta_path is empty lines.

@w1ndy

This comment has been minimized.

Copy link
Contributor

w1ndy commented Apr 26, 2015

hi @kynikos , I reproduced segfault with your configuration when closing qtile before Xephyr. Could you please try again with w1ndy/qtile@a72aa3e and see if segfault goes away and dbus works normally?

@w1ndy

This comment has been minimized.

Copy link
Contributor

w1ndy commented Apr 26, 2015

Also you could try w1ndy/qtile@416e14b . GObject thread in this commit uses event loop.

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented Apr 27, 2015

Yep, both commits seem to exit cleanly for me too! What do you mean by "see if [...] dbus works normally"?

@w1ndy

This comment has been minimized.

Copy link
Contributor

w1ndy commented Apr 27, 2015

I'm not familiar with dbus and this piece of code uses the suggested method mentioned in GObject reference manual. I don't know whether it will work perfectly, but I guess so ;)

@w1ndy w1ndy mentioned this pull request Apr 27, 2015
tych0 added a commit to tych0/qtile that referenced this pull request May 15, 2015
In particular, avoid the use of __del__ as a finalizer. This has several
problems: it isn't necessarily run at all, and if it is, it isn't necessarily
run at a specific point in time (i.e. when the xcb connection is still open).

I belive this should also fix the segfault, and prevent us from leaking the
pixmaps drawer allocates when we exec.

Possible fix for qtile#658
@tych0

This comment has been minimized.

Copy link
Member

tych0 commented May 15, 2015

Ok, I forgot that I had this finalizer commit laying around from a plane ride a while ago. I think (?) this should fix the problem, and it's the right way to do it anyway. Can someone test this? :D

@kynikos

This comment has been minimized.

Copy link
Contributor

kynikos commented May 16, 2015

Sorry tych0, your branch is still segfaulting for me... ^^

flacjacket added a commit to flacjacket/qtile that referenced this pull request Jul 8, 2015
In particular, avoid the use of __del__ as a finalizer. This has several
problems: it isn't necessarily run at all, and if it is, it isn't necessarily
run at a specific point in time (i.e. when the xcb connection is still open).

I belive this should also fix the segfault, and prevent us from leaking the
pixmaps drawer allocates when we exec.

Possible fix for qtile#658
@flacjacket

This comment has been minimized.

Copy link
Member

flacjacket commented Jul 16, 2015

I was playing around with @tych0 's finalizers and I realized I'm getting the segfaults without pygobject installed, so there is at least one problem with our cffi handling. I get a backtrace very similar to @kynikos:

2015-07-15 21:11:35,632 qtile init_log:105  Starting Qtile
2015-07-15 21:11:35,889 qtile safe_import:49  Can't Import Widget: '.launchbar.LaunchBar', No module named 'xdg'
2015-07-15 21:11:35,891 qtile safe_import:49  Can't Import Widget: '.mpdwidget.Mpd', No module named 'mpd'
2015-07-15 21:11:35,896 qtile safe_import:49  Can't Import Widget: '.wlan.Wlan', No module named 'pythonwifi'
2015-07-15 21:11:35,896 qtile safe_import:49  Can't Import Widget: '.google_calendar.GoogleCalendar', No module named 'httplib2'
2015-07-15 21:11:35,897 qtile safe_import:49  Can't Import Widget: '.imapwidget.ImapWidget', No module named 'keyring'
2015-07-15 21:11:35,902 py.warnings <module>:32  /usr/lib64/python3.4/imp.py:32: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  PendingDeprecationWarning)

2015-07-15 21:11:36,054 qtile setup_python_dbus:268  importing dbus/gobject failed, dbus will not work.

Program received signal SIGTERM, Terminated.
0x00007ffff7478533 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:81
81      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff17680e0 in ?? ()
(gdb) bt
#0  0x00007ffff17680e0 in ?? ()
#1  0x00007ffff21a4010 in ffi_call_unix64 () at /var/tmp/portage/dev-libs/libffi-3.2.1/work/libffi-3.2.1/src/x86/unix64.S:76
#2  0x00007ffff21a3a78 in ffi_call (cif=<optimized out>, fn=<optimized out>, rvalue=0x7ffff6c0bfb0, avalue=0x7ffff6c0bfa8)
    at /var/tmp/portage/dev-libs/libffi-3.2.1/work/libffi-3.2.1/src/x86/ffi64.c:525
#3  0x00007ffff2493952 in ?? () from /usr/lib64/python3.4/site-packages/_cffi_backend.cpython-34.so
#4  0x00007ffff79a85e8 in PyObject_Call (func=func@entry=<_cffi_backend.CData at remote 0x7fffead4f670>, 
    arg=arg@entry=(<_cffi_backend.CData at remote 0x7fffead4f3f0>,), kw=kw@entry=0x0)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/abstract.c:2040
#5  0x00007ffff79a917c in PyObject_CallFunctionObjArgs (callable=<_cffi_backend.CData at remote 0x7fffead4f670>)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/abstract.c:2332
#6  0x00007ffff248a1ce in ?? () from /usr/lib64/python3.4/site-packages/_cffi_backend.cpython-34.so
#7  0x00007ffff79a85e8 in PyObject_Call (func=func@entry=<built-in method gc_wref_remove of tuple object at remote 0x7fffead61cc8>, 
    arg=arg@entry=(<weakref at remote 0x7fffeacefea8>,), kw=kw@entry=0x0) at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/abstract.c:2040
#8  0x00007ffff79a917c in PyObject_CallFunctionObjArgs (callable=callable@entry=<built-in method gc_wref_remove of tuple object at remote 0x7fffead61cc8>)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/abstract.c:2332
#9  0x00007ffff7a362e3 in handle_callback (ref=ref@entry=0x7fffeacefea8, 
    callback=callback@entry=<built-in method gc_wref_remove of tuple object at remote 0x7fffead61cc8>)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/weakrefobject.c:868
#10 0x00007ffff7a39250 in PyObject_ClearWeakRefs (object=<optimized out>)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/weakrefobject.c:915
#11 0x00007ffff2488a40 in ?? () from /usr/lib64/python3.4/site-packages/_cffi_backend.cpython-34.so
#12 0x00007ffff79e1377 in dict_dealloc (mp=0x7fffead1f8c8) at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/dictobject.c:1383
#13 0x00007ffff79f9d82 in subtype_clear (self=<Context at remote 0x7fffeacf4588>)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Objects/typeobject.c:1047
#14 0x00007ffff7a94482 in delete_garbage (old=<optimized out>, collectable=<optimized out>)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/gcmodule.c:866
#15 collect (generation=generation@entry=2, n_collected=n_collected@entry=0x0, n_uncollectable=n_uncollectable@entry=0x0, nofail=nofail@entry=1)
    at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/gcmodule.c:1032
#16 0x00007ffff7a95101 in _PyGC_CollectNoFail () at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/gcmodule.c:1638
#17 0x00007ffff7a6f4a0 in PyImport_Cleanup () at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Python/import.c:536
#18 0x00007ffff7a7bb64 in Py_Finalize () at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Python/pythonrun.c:616
#19 0x00007ffff7a93014 in Py_Main (argc=0, argv=0x0) at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/main.c:771
#20 0x0000000000400b06 in main (argc=4, argv=<optimized out>) at /var/tmp/portage/dev-lang/python-3.4.3/work/Python-3.4.3/Modules/python.c:69
(gdb) py-bt-full 
#15 Garbage-collecting
(gdb) 
flacjacket added a commit to flacjacket/qtile that referenced this pull request Jul 16, 2015
In particular, avoid the use of __del__ as a finalizer. This has several
problems: it isn't necessarily run at all, and if it is, it isn't necessarily
run at a specific point in time (i.e. when the xcb connection is still open).

I belive this should also fix the segfault, and prevent us from leaking the
pixmaps drawer allocates when we exec.

Possible fix for qtile#658
@flacjacket flacjacket mentioned this pull request Jul 16, 2015
@flacjacket

This comment has been minimized.

Copy link
Member

flacjacket commented Jul 16, 2015

See if #702 does the trick, I was able to get it working for me, so at least one of the segfaults should be cleared up. I tried to make the GObject stuff finalize nicely, but I don't know if I got it right, and I don't have it installed right now to check.

flacjacket added a commit that referenced this pull request Jul 19, 2015
In particular, avoid the use of __del__ as a finalizer. This has several
problems: it isn't necessarily run at all, and if it is, it isn't necessarily
run at a specific point in time (i.e. when the xcb connection is still open).

I belive this should also fix the segfault, and prevent us from leaking the
pixmaps drawer allocates when we exec.

Possible fix for #658
@flacjacket

This comment has been minimized.

Copy link
Member

flacjacket commented Jul 19, 2015

I don't think daemonizing the gobject thread is the right thing to do here, it should be shut down properly. The changes I just pushed were able to clear up the segfault with the back trace posted above, though I haven't yet tried to reproduce the xcffib segfault

flacjacket added a commit to flacjacket/qtile that referenced this pull request Jul 19, 2015
In particular, avoid the use of __del__ as a finalizer. This has several
problems: it isn't necessarily run at all, and if it is, it isn't necessarily
run at a specific point in time (i.e. when the xcb connection is still open).

I belive this should also fix the segfault, and prevent us from leaking the
pixmaps drawer allocates when we exec.

Possible fix for qtile#658
kseistrup added a commit to kseistrup/qtile that referenced this pull request Aug 13, 2015
In particular, avoid the use of __del__ as a finalizer. This has several
problems: it isn't necessarily run at all, and if it is, it isn't necessarily
run at a specific point in time (i.e. when the xcb connection is still open).

I belive this should also fix the segfault, and prevent us from leaking the
pixmaps drawer allocates when we exec.

Possible fix for qtile#658
hallyn added a commit to hallyn/qtile that referenced this pull request Dec 3, 2015
In particular, avoid the use of __del__ as a finalizer. This has several
problems: it isn't necessarily run at all, and if it is, it isn't necessarily
run at a specific point in time (i.e. when the xcb connection is still open).

I belive this should also fix the segfault, and prevent us from leaking the
pixmaps drawer allocates when we exec.

Possible fix for qtile#658
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.