Mantis Bugtracker
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
Reporter wiz View Status public  
Assigned To laza
Priority normal Resolution fixed  
Status closed   Product Version
Summary 0007213: [big bug] morph>>extent: now does rounding and that can lead to infinite loops.
Description 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.
 
Additional Information 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:

extent: aPoint

    bounds extent = aPoint ifTrue: [^ self].
    self changed.

+ bounds _ (bounds topLeft extent: aPoint) rounded.
- bounds _ bounds topLeft extent: aPoint.

    self layoutChanged.
    self changed.

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?

Attached Files

- Relationships

SYSTEM WARNING: Creating default object from empty value

related to 0007212new  Mother for flaptab issues 
has duplicate 0006486closed laza In 7097 Resizing the objects flaptab can result in a infinite loop (i.e. squeak freezes) 
related to 0007635closed andreas Graphics primitives will raise errors when rectangles have widths in fractions. 

- Notes
(0012735 - 55 - 61 - 61 - 61 - 61 - 61)
wiz
10-13-08 02:57
Reminder sent to: laza

Hi laza,
Could you give this a think and then comment?
 
(0012736 - 1568 - 1963 - 2167 - 2167 - 2167 - 2167)
laza
10-13-08 07:44

 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
different way...

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.

Alex

extent: aPoint
        bounds extent = aPoint ifTrue: [^ self].
        self changed.
        bounds _ bounds topLeft extent: aPoint.
        self layoutChanged.
        self changed.
 
(0012737 - 567 - 699 - 903 - 903 - 903 - 903)
laza
10-13-08 07:45

 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
3.7alpha image.

Alex

| 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)
nicolas cellier
10-13-08 22:46

 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)
laza
04-08-10 09:38

 I used Nicolas idea and used closeTo: instead of = in extent:
 

- Issue History
Date Modified Username Field Change
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.
Powered by Mantis Bugtracker