Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] Re: Tile and LayerGeneratedGlyphDecorator locking up

Still it is a clue; the author must of being using the tiled renderer
correct? (or is this from a WMS-C layer?). I would like to see if this
kind of error is produced from SWT running out of image references;
Jesse ran into a similar situtation with widgets and I would like to
know if SWT will deadlock (ie wait for an image to be free) or if it
will just fail.

Jody

On Tue, Apr 21, 2009 at 2:50 AM, Graham Davis <gdavis@xxxxxxxxxxxxxxx> wrote:
> I believe this is my code.  Jody, the disposeSWTImage() method only disposes
> of the image if it is not null.  I'm not sure why this would be locking in
> Linux only (that seems very odd).  Unfortunately I don't have a version of
> Linux to test this with either.
>
> Graham.
>
>
> Emily Gouge wrote:
>>
>> I don't remember writing this code but I think maybe Graham and I worked
>> on it together.
>>
>> Looking a little further this may be a locking issue.  Inside the
>> disposeSWTImage() function is the following code:
>>
>> synchronized (SWTLock) {
>>  if (swtImage != null) {
>>    swtImage.dispose();
>>    swtImage = null;
>>  }
>> }
>>
>> So I suspect that it's getting hung up waiting for SWTLock, but I have no
>> idea why.  The only other place when this lock is used is in the
>> createSWTImage function...
>>
>> synchronized (SWTLock) {
>>  // if the SWTImage is created once the lock is gained, exit
>>  if (swtImage != null && !swtImage.isDisposed()) {
>>    return;
>>  }
>>  // otherwise try creating the SWTImage now
>>  try {
>>    BufferedImage buffImage = getBufferedImage();
>>    swtImage = AWTSWTImageUtils.createSWTImage(buffImage, false);
>>  } catch (Exception ex) {
>>    ex.printStackTrace();
>>  }
>> }
>>
>> I don't have a linux version to investigate this further.
>>
>> Emily
>>
>>
>> Jody Garnett wrote:
>>>>
>>>> So here are some more data points...
>>>
>>> Great detective work.
>>>
>>>>                try {
>>>> -                    boolean notifyIcon = refreshIcon(layer);
>>>> +                    boolean notifyIcon = true;
>>>>
>>>>                    boolean notifyLabel = refreshLabel(layer);
>>>>
>>>> And voila, no more lock ups!  Well, until it happened again so traced
>>>> back again and did the following...
>>>>
>>>> #P net.refractions.udig.project
>>>> Index: src/net/refractions/udig/project/render/Tile.java
>>>> ===================================================================
>>>> --- src/net/refractions/udig/project/render/Tile.java   (revision 31218)
>>>> +++ src/net/refractions/udig/project/render/Tile.java   (working copy)
>>>> @@ -147,7 +147,7 @@
>>>>  //                         System.out.println((msg.getNewIntValue() ==
>>>> IRenderer.DONE)  + "; state = done");
>>>>                           if(  swtImage == null ||
>>>> msg.getNewIntValue()==IRenderer.DONE){
>>>>                               //we only care about done events
>>>> -                               disposeSWTImage();
>>>> +//                             disposeSWTImage();
>>>>                           }
>>>>                       }
>>>>                   }
>>>>
>>>> Which has "cured" the lock up problem so far.  Obviously this really
>>>> isn't a proper fix, but it is allowing me to make progress on my
>>>> prototype.
>>>
>>> This last one looks suspicions to me; I would only try displosing the
>>> image if it was != null for example :-)
>>> Emily - this is your Tile code am I reading it correct?
>>>
>>> It appears as if we are leaking SWT images; and the linux
>>> implementation is calling our bluff and making us wait
>>>
>>> Jody
>>
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
> --
> Graham Davis
> Refractions Research Inc.
> gdavis@xxxxxxxxxxxxxxx
>
>


Back to the top