|Anonymous | Login||07-08-2020 15:15 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0007213||[Squeak] Morphic||crash||sometimes||10-13-08 02:56||04-18-10 21:51|
|Summary||0007213: [big bug] morph>>extent: now does rounding and that can lead to infinite loops.|
in a fresh 3.10.2
put halos around a flaptab (objects, squeak demonstrate this bug)
drag the yellow expand button.
The system will hang until interupted by cmd-.
see 0006486 for more info incl a test and a fix.
this issue is to focus on the code in Morph>>extent:
+ 'laza 3/25/2004 21:31 Morph extent:'
- 'di 8/22/2000 07:45 Morph extent:
bounds extent = aPoint ifTrue: [^ self].
+ bounds _ (bounds topLeft extent: aPoint) rounded.
- bounds _ bounds topLeft extent: aPoint.
This is a recursively writen method. The test condition at the top is to allow the recursion to stop.
This worked in dan's implementation because
if the condition was false
the bounds were set s.t. the condition would be true.
However laza's patch violated that assumption.
If you have an integer extent point for a morph without an integer position point then the assumption is violated.
If the layout has cause to send #extent: , even with the same extent point, the condition may fail.
Then it's off to the races, the infinite races.
Worse rectangles will not maintain their shape when rounded (or when truncated.)
So that is not what you want to do.
The result is all those gribbles you see morphic objects leaving on the screen.
So my favored solution would be to revert to dan's simpler implementation and deal with the consequences. Squeak's practice of agressively rounding is very wrong. It leads to numerous problems.
I am putting up a separate report because I would like help in finding specific classes and methods affected by the reversion.
I would also like to find out what laza was trying to accomplish with his change?
SYSTEM WARNING: Creating default object from empty value
(0012735 - 55 - 61 - 61 - 61 - 61 - 61)
Reminder sent to: laza
Could you give this a think and then comment?
(0012736 - 1568 - 1963 - 2167 - 2167 - 2167 - 2167)
This is from http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-March/076159.html [^]
After I loaded all recent updates for 3.7alpha and my
HilightCurrentFontChoices changeset, I got an infinite loop when setting the
flap font. At first I thought I broke something with the 'enhancement', but
it happened also without it. Strangely enough everything worked in another
image without the recent updates. So I looked into the updates to see if
something strange has happened meanwhile. I couldn't find a thing. Then I
tried to find the reason for the infinite loop. I think Morph>extent: is
causing the loop in some cases where a FlapTab Morph boundary contains
floats. In these cases the expression 'bounds extent = aPoint' will evaluate
to false because of rounding errors. The layoutChanged method of FlapTab
sends an extent: message again and because of the failing condition it runs
in an infinite loop.
The attached changeset prevents this by rounding boundary values, although I
don't know if it is the best way to do it. Maybe it would be better to make a
special extent: method in FlapTab or to deal with this in a completely
I think this phenomenon is the same that Jim Benson reported almost a
year ago ([BUG] setFlapsFontTo: 32 bit display (9 April 2003), but he
suspected a different cause.
bounds extent = aPoint ifTrue: [^ self].
bounds _ bounds topLeft extent: aPoint.
(0012737 - 567 - 699 - 903 - 903 - 903 - 903)
This is from http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-March/076176.html [^]
Because maybe most of you think I'm seeing white mice here I made a
testcase. I got the values a and b from an existing FlapTab morph in an
| a b tab |
"Create a float close to 466.700581395349"
a _ (1.1 at: 1 put: 1081944885; at: 2 put: 2497074009; yourself).
b _ 105.
a + b - a = b. "This evaluates to false"
tab _ Flaps newFlapTitled: 'Test' onEdge: #top.
tab left: a.
"next line will run into an infinite loop"
tab extent: b at b
(0012738 - 207 - 219 - 219 - 219 - 219 - 219)
Maybe it's the perfect place for using #closeTo: (extending it to Point).
I always thought this message was created for graphics, because of its relatively low resolution. It happen to not be thse case...
(0013637 - 61 - 61 - 61 - 61 - 61 - 61)
|I used Nicolas idea and used closeTo: instead of = in extent:|
|10-13-08 02:56||wiz||New Issue|
|10-13-08 02:57||wiz||Issue Monitored: laza|
|10-13-08 02:57||wiz||Note Added: 0012735|
|10-13-08 02:58||wiz||Relationship added||related to 0007212|
|10-13-08 02:58||wiz||Relationship added||related to 0006486|
|10-13-08 07:44||laza||Note Added: 0012736|
|10-13-08 07:45||laza||Note Added: 0012737|
|10-13-08 22:46||nicolas cellier||Note Added: 0012738|
|04-08-10 09:35||laza||Status||new => assigned|
|04-08-10 09:35||laza||Assigned To||=> laza|
|04-08-10 09:38||laza||Status||assigned => resolved|
|04-08-10 09:38||laza||Fixed in Version||=> trunk|
|04-08-10 09:38||laza||Resolution||open => fixed|
|04-08-10 09:38||laza||Note Added: 0013637|
|04-08-10 09:39||laza||Relationship replaced||has duplicate 0006486|
|04-18-10 21:51||andreas||Status||resolved => closed|
|05-30-11 23:07||wiz||Relationship added||related to 0007635|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
73 total queries executed.|
47 unique queries executed.