Anonymous | Login | 02-27-2021 22:29 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 | ||||
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 | |||||||||
|
![]() |
||||||||||||||||
SYSTEM WARNING: Creating default object from empty value
|
![]() |
|
(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: |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
73 total queries executed. 47 unique queries executed. |