GoogleCodeExporter
commented
8 years ago Issue 932 has been merged into this issue.Original comment by gbtami on 10 Dec 2014 at 8:22
Open GoogleCodeExporter opened 8 years ago
GoogleCodeExporter
commented
8 years ago Issue 932 has been merged into this issue.Original comment by gbtami on 10 Dec 2014 at 8:22
GoogleCodeExporter
commented
8 years ago This is occurring because the crashing thread (FICSConnection) isn't acquiring
the glock before calling Infobar.push_message().Original comment by mattgatto on 11 Dec 2014 at 12:01
GoogleCodeExporter
commented
8 years ago 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-sta
ckswitcher
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.Original comment by mattgatto on 11 Dec 2014 at 12:50
GoogleCodeExporter
commented
8 years ago 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.Original comment by gbtami on 18 Jan 2015 at 9:30
Original issue reported on code.google.com by
gbtamion 15 Nov 2014 at 11:42Attachments: