|Anonymous | Login||08-09-2020 08:22 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|
|0006591||[Squeak] Balloon||crash||always||08-06-07 17:42||08-06-07 17:43|
|Summary||0006591: A hard crash from a project that manipulates Oriented fills|
While working on a project to allow fills to be manipulated via handles, I found it was possible to crash the image repeatedly under certain circumstances.
It starts with a radial gradient fill. (I use GradientFillStyle sample in the project)
Basicly if I requested a fill with a very small direction/normal at some unspecified angle (hey it crashed, forensics are hard to do.)
Then the image would freeze ( Cmd-. had no effect), there would be a period of waiting (usually less than a minute.) and then the Finder would report the image had quit due to a bus-error (which I take to mean an out-of-memory problem of some kind.)
The cause of the bug here is not clear or certain.
And there are probably at least two.
One to cause an infinite loop. And one to cause the crash and the exhaustion of resources. (No bug logs or warnings come before the crash.
For the purposes of my project I increased the limit radius from 1 to 4 and that seems to prevent the bug.
I report it here because of its seriousness. And I will upload an offending version of the project.
I am on an old iMac G3 Os9.1 vm is SqVM3.8.9b7 Classic and the image a fresh 7137.
I have seen the bug on earlier images.
I am hoping for two types of feedback.
Pinning down the bugs.
First is the crash bug reproducable on more modern vms? Or will it fail more gently?
Is it reproducable on other OSes? Even ones similar to mine. I use my mac on the internet and something I am not able to detect may have happened to it.
Secondly, assuming the problem is in essence reproducable across platforms, where are the bugs?
The fact that originating problem is not interuptable suggests looking in the radial fill code for a problem. I have not been able to reproduce the problem when the radial flag is set to false.
The fact that the image crashs means that there is also probably an out-of-memory fail safe missing.
I can't track down either of them from my system. My setup and Os do not permit me to examing the crash. But someone who has a system that would provide crash data can probably track down the second and maybe trace back to find the first.
I am uploading the offending project. It has the
1) "FillHandleFactory example3" set up on the screen.
2) Move the yellow scale handle towards the center of the fill
till the handles overlap.
3) If that doesn't cause the bug to appear
switching to the blue rotate handle
(which is now on top of all the overlaping handles)
will usually suffice.
Please report negative (it didn't crash) as well as positive (it did) results here.
And of course any insights.
I am also uploading the corresponding changeset in case there are problems loading the file. After installing the cs start with step one above as a doit and proceed with the following steps.
The handles and examples are using MixedCurveMorph polygons so they depend on 3dot9 or later or having loaded the MixedCurveMorph enhancement to an earlier system.
fillHandles-wiz.049.pr [^] (148,071 bytes) 08-06-07 17:42
Crash-fillHandles-wiz.1.cs [^] (22,481 bytes) 08-06-07 17:43
|There are no notes attached to this issue.|
|08-06-07 17:42||wiz||New Issue|
|08-06-07 17:42||wiz||Status||new => assigned|
|08-06-07 17:42||wiz||Assigned To||=> andreas|
|08-06-07 17:42||wiz||File Added: fillHandles-wiz.049.pr|
|08-06-07 17:43||wiz||File Added: Crash-fillHandles-wiz.1.cs|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
34 total queries executed.|
27 unique queries executed.