sporadic AssertionErrors about is_executing

[Brendan]

Sometimes, for no apparent reason, DreamPie crashes with an AssertionError. The crash window displays the following info:

-----
Variables:
  File "C:\Program Files\DreamPie\dreampielib\gui\subprocess_handler.py", line 203, _manage_subp(self=<dreampi...01413690>)
    {'self._on_object_recv': <bound method DreamPie.on_object_recv of DreamPie(path="C:\Program Files\DreamPie\share\dreampie\dreampie.glade", root="window_main")>, 'obj': (True, None, None, None, u'')}
  File "C:\Program Files\DreamPie\dreampielib\gui\__init__.py", line 886, on_object_recv(self=DreamPie(path..."window_main"), obj=(True, None, None, None, u''))
    {'self.is_executing': False}

Traceback (most recent call last):
  File "C:\Program Files\DreamPie\dreampielib\gui\subprocess_handler.py", line 203, in _manage_subp
    self._on_object_recv(obj)
  File "C:\Program Files\DreamPie\dreampielib\gui\__init__.py", line 886, in on_object_recv
    assert self.is_executing
AssertionError
-----

I can't find any rhyme or reason to what causes this, it just sometimes dies.

I also tried running it with the -O flag to ignore assertions. In this case it seems to periodically get into an unresponsize state where entering commands has no effect. I can still type and hit enter and the display updates, but the commands aren't executed, they just show up in the output window. I can't determine whether this frozen state is caused at the same times when it would have otherwise thrown an AssertionError.

It seems that somewhere in the internals of DreamPie something is amiss with the is_executing flag, and it sometimes tries to execute something before it's done with the previous one, or some such thing, but I don't know enough about how DreamPie works to say more at this point.

[Brendan (brenbarn)]

I seem to have fixed this bug by changing two lines in the execute_source method in dreampielib/gui/__init__.py. The last two lines of the method are:

self.vadj_to_bottom.scroll_to_bottom()
self.set_is_executing(True)

I just switched the order of these two lines. My guess is that some sort of timing issue sometimes occurred during the redraw associated with scrolling to the bottom, where during the scroll it tried to do something believing it was executing, but it wasn't, because it hadn't reached the set_is_executing line. I saw that the code in crash_workaround.py was being triggered during these crashes. Switching the order of the two lines appears to fix it by ensuring that the code is marked as "executing" during the scroll. However, I don't understand the internals of what's going on here well enough to know if this is a real fix, or what really caused it.

[Noam Yorav-Raphael (noamraph)]

Thanks for the detailed report, and sorry for the late reply!

Indeed, it is possible that updating the display caused further events to be processed, and the result was received before
set_is_executing(True) was called.

I now moved to github, and fixed according to your suggestion, in commit 32476b90c0315f6a63d7ed6b0cbec9c32f474cb4.
Please see the instructions in www.dreampie.org/download.html to clone the git repo and see if it now works.

Thanks again!
Noam