You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by George Armhold <ar...@cs.rutgers.edu> on 2003/10/30 17:11:36 UTC
race condition in JSVGComponent/RunnableQueue ?
Hi,
I have a small program that demonstrates a problem with JSVGComponent.
I run an infinite loop that alternates the loading of two SVG docs.
After running for a while, a race condition appears to cause one of
the documents to get "stuck" in the canvas; subsequent calls to
setSVGDocument seem to have no effect. The canvas seems "alive"
insofar as responding to window resizes/redraws, but the
setSVGDocument never seems to have any effect. I suspect that a
thread is starving in a RunnableQueue somewhere. Perhaps this has
something to do with it:
http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03651.html
?
I've attached the sample program. You might need to adjust the
argument to sleep for your platform. The 400 works for me on my Linux
box.
Thanks for your attention.
--
George Armhold
Rutgers University
eLearning Grant, DCIS
Re: race condition in JSVGComponent/RunnableQueue ?
Posted by Mitch Germansky <mb...@dragon.rutgers.edu>.
> Can you provide more information. What test files you were
> using etc. I couldn't get it to 'lock' up.
hi, i work with george and was also able to reproduce the "lock-up" on
linux (rh7.3) every time using 400. i am attaching the 2 svg files i
used when i tested it. see attached testfiles.tar.gz with page1.svg and
test2.svg -- george tested with different test files on a different
linux box (rh9) (note these svg files are generated from OOo svg export
originating from ppt source). george also tested on winxp although he
told me it took longer for the lockup to occur on winxp.
thanks a lot for all your help!!
Re: race condition in JSVGComponent/RunnableQueue ?
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> I believe I have this fixed. I'll be committing it shortly.
Hi Thomas,
I just re-built batik from a fresh CVS update. Now I get the
following NPE with CanvasTest.
java.lang.NullPointerException
at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
Also, the bug seems to still be here. :-( After a few iterations the
canvas gets stuck on one of the images. For the time being, I am
testing this with "mathMetal" and "anne".
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: race condition in JSVGComponent/RunnableQueue ?
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
>
>> Can you provide more information. What test files you were using
>> etc.
>
> My colleague Mitch just mailed a couple of samples to the list. But I
> am able to make it hang with pretty much any 2 files from the samples
> directory. For example "anne" and "mathMetal".
I believe I have this fixed. I'll be committing it shortly.
FYI, the issue was that the UpdateManager calls back it's event
listeners in the Update Thread. This means that The UpdateManager
could be in the processes of delivering a Manager Stopped event
(having already copied the list of objects to notify). This
means that the Canvas ends up waiting for an event that will never happen.
> What platform are you testing on? Under WinXP it seems to happen only
> after many iterations. I noticed that resizing the window sometimes
> makes it happen sooner.
I'm testing on Win 2000. I finally got it to happen once
(I let it run for an afternoon) which let me take a look at the
thread dump and get a clearer idea what sort of issue was at the root of it.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: race condition in JSVGComponent/RunnableQueue ?
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> Can you provide more information. What test files you were using
> etc.
My colleague Mitch just mailed a couple of samples to the list. But I
am able to make it hang with pretty much any 2 files from the samples
directory. For example "anne" and "mathMetal".
> I tried varying the length from about 200ms to 800ms and while I
> would get long stretches of one image I would eventually get one of
> the others (and it was always blanking then showing image blanking
> showing image etc - which I think means that even when I got long
> stretches of the same image it was still trying to load each of the
> images it's just that that image was making it far enough along to
> get displayed).
I first noticed the problem when using a JSlider to navigate among a
dozen or so documents. The slider moved slowly, because
setSVGDocument is a somewhat slow process, and I needed to call it via
the Swing thread. However once the canvas got stuck, the slider
suddenly became much more lively, apparently because setSVGDocument
was returning very quickly; it seemed like it was doing no work at
all. However since the JSlider was user-driven, it was hard to
reproduce. So then I came up with the "swap two documents" approach,
which seems to be more predictable.
What platform are you testing on? Under WinXP it seems to happen only
after many iterations. I noticed that resizing the window sometimes
makes it happen sooner. Sorry this is so vague. Thanks for
investigating this.
BTW this is Batik-1.5 from CVS.
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: race condition in JSVGComponent/RunnableQueue ?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Thomas DeWeese wrote:
> George Armhold wrote:
>
>> I have a small program that demonstrates a problem with JSVGComponent.
>
> Thanks for putting it together I'll take a look at it.
>>
>> I've attached the sample program. You might need to adjust the
>> argument to sleep for your platform. The 400 works for me on my Linux
>> box.
Can you provide more information. What test files you were
using etc. I couldn't get it to 'lock' up. I tried using various
combinations of images (sydney, 3D, starfield - in various combinations,
anne and moonPhases, etc) I tried varying the length from about
200ms to 800ms and while I would get long stretches of one image
I would eventually get one of the others (and it was always
blanking then showing image blanking showing image etc - which I
think means that even when I got long stretches of the same image
it was still trying to load each of the images it's just that that
image was making it far enough along to get displayed).
I did get one exception with a timer, which I believe I have
corrected, but even that did not lock up the image display.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: race condition in JSVGComponent/RunnableQueue ?
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> I have a small program that demonstrates a problem with JSVGComponent.
Thanks for putting it together I'll take a look at it.
> I run an infinite loop that alternates the loading of two SVG docs.
> After running for a while, a race condition appears to cause one of
> the documents to get "stuck" in the canvas; subsequent calls to
> setSVGDocument seem to have no effect. The canvas seems "alive"
> insofar as responding to window resizes/redraws, but the
> setSVGDocument never seems to have any effect. I suspect that a
> thread is starving in a RunnableQueue somewhere. Perhaps this has
> something to do with it:
>
> http://koala.ilog.fr/batik/mlists/batik-dev/archives/msg03651.html
>
> ?
>
> I've attached the sample program. You might need to adjust the
> argument to sleep for your platform. The 400 works for me on my Linux
> box.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org