Issue 925 in pychess: Fatal Python error: Segmentation fault while playing on FICS

[pyc...@googlecode.com]

Status: Accepted
Owner: gbtami
Labels: Type-Defect Python-Crash

New issue 925 by gbtami: Fatal Python error: Segmentation fault while
playing on FICS
https://code.google.com/p/pychess/issues/detail?id=925

Fatal Python error: Segmentation fault

Thread 0xad3feb40:
File "/usr/lib/python2.7/threading.py", line 339 in wait
File "/usr/lib/python2.7/Queue.py", line 168 in get
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/System/GtkWorker.py",
line 29 in run
File "/usr/lib/python2.7/threading.py", line 810 in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 783 in __bootstrap

Thread 0xadbffb40:
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/FICSConnection.py",
line 214 in keep_alive
File "/usr/lib/python2.7/threading.py", line 763 in run
File "/usr/lib/python2.7/threading.py", line 810 in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 783 in __bootstrap

Thread 0xae5ffb40:
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/FICSConnection.py",
line 214 in keep_alive
File "/usr/lib/python2.7/threading.py", line 763 in run
File "/usr/lib/python2.7/threading.py", line 810 in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 783 in __bootstrap

Thread 0xaefffb40:
File "/usr/lib/python2.7/threading.py", line 339 in wait
File "/usr/lib/python2.7/Queue.py", line 168 in get
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/System/GtkWorker.py",
line 29 in run
File "/usr/lib/python2.7/threading.py", line 810 in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 783 in __bootstrap

Thread 0xaf9ffb40:
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/TimeSeal.py", line
170 incook_some
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/TimeSeal.py", line
167 inreaduntil
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/TimeSeal.py", line
155 inreadline
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/VerboseTelnet.py",
line 161 in _get_lines
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/VerboseTelnet.py",
line 156 in popleft
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/VerboseTelnet.py",
line 206 in parse
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/FICSConnection.py",
line 231 in run
File "/usr/lib/python2.7/threading.py", line 810 in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 783 in __bootstrap

Current thread 0xb15e1b40:
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/widgets/InfoBar.py",
line 186 in _load_message
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/widgets/InfoBar.py",
line 215 in push_message
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/widgets/gamewidget.py",
line663 in showMessage
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/widgets/gamewidget.py",
line670 in replaceMessages
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/widgets/gamenanny.py",
line 180 in game_ended
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/Utils/GameModel.py",
line 713 in end
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/ICGameModel.py", line
218in end
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/ICGameModel.py", line
128in onGameEnded

File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/managers/BoardManager.py",
line 766 in onGameEnd
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/FICSObjects.py", line
948in game_ended

File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/managers/HelperManager.py",
line 130 in on_game_remove
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/VerboseTelnet.py",
line 49 in handle
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/VerboseTelnet.py",
line 222 in test_prediction
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/VerboseTelnet.py",
line 213 in parse
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/ic/FICSConnection.py",
line 231 in run
File "/usr/lib/python2.7/threading.py", line 810 in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 783 in __bootstrap

Thread 0xb0bffb40:
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/System/debug.py", line
29 inthread_dumper
File "/usr/lib/python2.7/threading.py", line 763 in run
File "/usr/lib/python2.7/threading.py", line 810 in __bootstrap_inner
File "/usr/lib/python2.7/threading.py", line 783 in __bootstrap

Thread 0xb7388980:
File "/mnt/uhu2.2/home/tamas/pychess/lib/pychess/Main.py", line 498 in run
File "./pychess", line 138 in <module>
Szegmentálási hiba (core készült)



Attachments:
2014-11-15_11-44-24.log.bz2 2.3 MB

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[pyc...@googlecode.com]

Updates:
Cc: mattgatto

Comment #1 on issue 925 by gbtami: Fatal Python error: Segmentation fault

while playing on FICS
https://code.google.com/p/pychess/issues/detail?id=925

Issue 932 has been merged into this issue.

[pyc...@googlecode.com]

Comment #2 on issue 925 by mattgatto: Fatal Python error: Segmentation

fault while playing on FICS
https://code.google.com/p/pychess/issues/detail?id=925

This is occurring because the crashing thread (FICSConnection) isn't
acquiring the glock before calling Infobar.push_message().

[pyc...@googlecode.com]

Comment #3 on issue 925 by mattgatto: Fatal Python error: Segmentation

fault while playing on FICS
https://code.google.com/p/pychess/issues/detail?id=925

I stand corrected, it does have the glock... It acquires it in gamenanny.py:
with glock.glock:
gmwidg.replaceMessages(message)

After all, the log does show the HelperConnection thread acquiring the
glock right before crashing.

Maybe this and issue 932 are the same bugs. Since it's not a locking issue,
I can only think of two things:
a) Maybe manipulating gtk.InfoBar internals like we do in
InfoBar._load_message as shown below isn't supposed to be done:
def _load_message (self, message):
for container in (self.get_action_area(), self.get_content_area()):
for widget in container:
container.remove(widget)
self.set_message_type(message.type)
self.get_content_area().add(message.content)

If this is the problem, a safer way to have a dialog stack might be to
simply add a new gtk.InfoBar for each new message instead of re-using the
same one. Even better, we could use a gtk.Stack with gtk.InfoBar's as the
displayed widget once we merge pygi (requires GTK+ 3.10).
http://lazka.github.io/pgi-docs/Gtk-3.0/classes/Stack.html#Gtk.Stack
http://python-gtk-3-tutorial.readthedocs.org/en/latest/layout.html#stack-and-stackswitcher

b) Some thread code somewhere or a bug in python or a python binding we use
is overwriting memory somewhere. This isn't out of the question as I've
noticed this very thing happening and leading to crashes in other places,
and objects containers with the wrong types of objects in them. For
example, in several instances I've seen FICSRatings objects having objects
other than a FICSRating in it, which shouldn't be possible through a code
path since FICSRatings type checks each object added to it and throws an
exception if it isn't a FICSRating object.

[pyc...@googlecode.com]

Comment #4 on issue 925 by gbtami: Fatal Python error: Segmentation fault

while playing on FICS
https://code.google.com/p/pychess/issues/detail?id=925

After the pygi merge I played several FICS games and got some
TypeError: 'NoneType' object is not iterable
from the same line (for container in etc...)
With some debugging print line I figured out that self.get_action_area() is
returning None in these cases. Anyhow, pygi at least handles this better
than pygtk, throwing an exception instead of segfaulting.