I was trying to merge tim's change with mine, so the image was definitely not clean. If I remember, I got such error first in a MC merge window.This involved many action, correcting SyntaxError, etc... breaking an image, killing the process, and restarting all over again. 2013/9/24 Bob Arning <[hidden email]>
|
I'll think about this some more, but my current
suspicion centers on:
styleInBackgroundProcess: aText self terminateBackgroundStylingProcess. stylingEnabled ifTrue:[ text := aText copy. self monitor critical: [ sem := Semaphore new. [sem notNil ifTrue: [ sem wait. view ifNotNil:[view stylerStyledInBackground: text]] ] forkAt: Processor activePriority. backgroundProcess := [self privateStyle: text. sem signal] forkAt: Processor userBackgroundPriority] ] I'm a little concerned about the ] forkAt: Processor activePriority. resulting in a process (1) running at the same priority as the UI process and (2) that will modify the state of a text morph on the screen. If such a modification is interrupted by a higher-priority process, the resumed process will not be the interrupted one, but the UI process which may proceed to display the world, includeing the partially modified text morph. If you can figure out how to make the error happen easily, then things to try: - increase the priority a bit [sem notNil ifTrue: [ sem wait. view ifNotNil:[view stylerStyledInBackground: text]] ] forkAt: Processor activePriority+1. - use WorldState addDeferredUIMessage: [view ifNotNil:[view stylerStyledInBackground: text]] instead of a separate process - disable background styling One or more of these might make the problem go away. Assuming you can force the problem to happen reliably. ;-) Cheers, Bob On 9/23/13 8:53 PM, Nicolas Cellier
wrote:
|
In reply to this post by Nicolas Cellier
One thing that would help for next time would
be saving all the stack traces (especially the first one). There
used to be a preference #appendToErrorLog that did just that. Easy
enough to add: just don't delete the old squeakdebug.log and do a
#setToEnd before writing. As it stands, the stack trace we have
doesn't say anything about how that text morph got that way.
Perhaps an earlier, more significant, error was overwritten and
that would have told us something.
Cheers, Bob On 9/23/13 8:53 PM, Nicolas Cellier
wrote:
|
In reply to this post by Nicolas Cellier
I've inserted a delay in TextMorph>>paragraph
when not running in the ui process to simulate getting
interrupted while building the new paragraph and it does recreate
your errors, including the warning message from MC. I still have not
convinced myself that such an interrupt is a high enough probability
to account for the number of times you have seen this error. But,
perhaps some combination of factors in your image make it more
likely. In any event, I think moving the actual updating of the
TextMorph to the UI process would be a good thing on general
principles.
Cheers, Bob On 9/23/13 8:53 PM, Nicolas Cellier
wrote:
|
Free forum by Nabble | Edit this page |