visualpython-users

[Visualpython-users] gdisplay objects seldom work

[Joe H. <hea...@vn...>]

Hi.

I'm running Mac OS X (10.2.6) and Visual 2.1.1 compiled from source. 
I'm still experiencing problems with gdisplay objects. If I create, for 
example, a graph with gcurve the program usually stalls upon execution, 
but no errors are indicated. Sometimes, roughly 90% of the time, both 
the main window and the graph window open up but the graph window is 
just blank and the other window, usually containing an animation of a 
physical system (e.g. oscillating spring-mass system) remains static. 
Sometimes, roughly 10% of the time, the graph shows up correctly, but 
NOT point by point. The entire graph is displayed after the animation 
is over, and the oscillating spring-mass never appears to move at all. 
On a very, very few occasions I get the correct output, which is an 
oscillating spring-mass system in one window and a graph updated in 
real time in the other window. However, I never ever get the program to 
work completely correctly twice in a row. Everything works fine when 
all the gdisplay related statements are commented out.

Another issue is that when a program that uses a gdisplay object 
terminates, the only way to remove the open windows is to choose "End 
program" from inside IDLE. Otherwise, the output windows remain active 
and can only be removed by opening up an xterm, issuing "top", getting 
the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of 
the correct python22 process.

Any ideas what's going on?

Cheers,
Joe Heafner

-----
New email address: hea...@ct...

Re: [Visualpython-users] gdisplay objects seldom work

[Bruce S. <bas...@un...>]

Jonathan Brandmeyer explained to me that there is a fundamental problem 
with which I was unaware. Recent versions of the Unix/Linux kernel no 
longer do "recursive" locking/unlocking of resources, something that 
Visual has used. Jonathan has been working on eliminating the deadlocks 
that can now occur and which may well be responsible for what you're 
seeing. He's doing this in his experimental Boost-based version but 
might retrofit the current Visual. This is not a problem on Windows.

Bruce Sherwood

Joe Heafner wrote:

> Hi.
>
> I'm running Mac OS X (10.2.6) and Visual 2.1.1 compiled from source. 
> I'm still experiencing problems with gdisplay objects. If I create, 
> for example, a graph with gcurve the program usually stalls upon 
> execution, but no errors are indicated. Sometimes, roughly 90% of the 
> time, both the main window and the graph window open up but the graph 
> window is just blank and the other window, usually containing an 
> animation of a physical system (e.g. oscillating spring-mass system) 
> remains static. Sometimes, roughly 10% of the time, the graph shows up 
> correctly, but NOT point by point. The entire graph is displayed after 
> the animation is over, and the oscillating spring-mass never appears 
> to move at all. On a very, very few occasions I get the correct 
> output, which is an oscillating spring-mass system in one window and a 
> graph updated in real time in the other window. However, I never ever 
> get the program to work completely correctly twice in a row. 
> Everything works fine when all the gdisplay related statements are 
> commented out.
>
> Another issue is that when a program that uses a gdisplay object 
> terminates, the only way to remove the open windows is to choose "End 
> program" from inside IDLE. Otherwise, the output windows remain active 
> and can only be removed by opening up an xterm, issuing "top", getting 
> the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of 
> the correct python22 process.
>
> Any ideas what's going on?
>
> Cheers,
> Joe Heafner
>
> -----
> New email address: hea...@ct...
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] gdisplay objects seldom work

[Roger F. <fe...@bi...>]

On Mon, 29 Sep 2003, Bruce Sherwood wrote:

> Jonathan Brandmeyer explained to me that there is a fundamental problem 
> with which I was unaware. Recent versions of the Unix/Linux kernel no 
> longer do "recursive" locking/unlocking of resources, something that 
> Visual has used. Jonathan has been working on eliminating the deadlocks 
> that can now occur and which may well be responsible for what you're 
> seeing. He's doing this in his experimental Boost-based version but 
> might retrofit the current Visual. This is not a problem on Windows.

Hi,
This problem looks like it is related to something I have noticed
on both Linux and Windows (98,2k,XP): gdisplay objects mostly work,
but occasionally they don't.
The result is a frozen window, usually displaying the minimum
axes possible (i.e. the problem seems to lie in the creation of the
window). 
In general, related activity in a display window will continue.
I guess that this is related to threading and some deadlock. I've
tried to trace through the code and find whereabouts the stall
is happening, but with little success - the usual problem with an
intermittent fault! However, some tests did seem to suggest that it got
lost between the exit from gdisplay's __init__ and the next call to the 
class instance.
One thing is that it does seem worse on machines that are a little tight 
on memory.
It is the one thing that does upset students a little with the visual 
package, otherwise they seem to like it.

Roger.

-- 
Roger Fearick
Dept. of Physics
University of Cape Town

Re: [Visualpython-users] gdisplay objects seldom work

[Bruce S. <bas...@un...>]

You're right. It's great that you've put your finger on a problem. I too 
am seeing programs with gdisplays (graphs) hanging more than any other 
kind of program, and on Windows as well as Linux, as you say. It is true 
that most of the multiwindow programs I run involve a graph, so it might 
be important to play with multiwindow programs that don't involve graphs 
to see whehter we see it there, too. But now that Jonathan has pointed 
to a possible problem area, might it be that contention is most likely 
to happen precisely in a program where we're constantly bouncing back 
and forth between windows, as is the case where an animation of a system 
is displayed in one window, and a corresponding graph is updated in 
another? What do you think, Jonathan?

Bruce Sherwood

Roger Fearick wrote:
> On Mon, 29 Sep 2003, Bruce Sherwood wrote:
> 
> 
>>Jonathan Brandmeyer explained to me that there is a fundamental problem 
>>with which I was unaware. Recent versions of the Unix/Linux kernel no 
>>longer do "recursive" locking/unlocking of resources, something that 
>>Visual has used. Jonathan has been working on eliminating the deadlocks 
>>that can now occur and which may well be responsible for what you're 
>>seeing. He's doing this in his experimental Boost-based version but 
>>might retrofit the current Visual. This is not a problem on Windows.
> 
> 
> Hi,
> This problem looks like it is related to something I have noticed
> on both Linux and Windows (98,2k,XP): gdisplay objects mostly work,
> but occasionally they don't.
> The result is a frozen window, usually displaying the minimum
> axes possible (i.e. the problem seems to lie in the creation of the
> window). 
> In general, related activity in a display window will continue.
> I guess that this is related to threading and some deadlock. I've
> tried to trace through the code and find whereabouts the stall
> is happening, but with little success - the usual problem with an
> intermittent fault! However, some tests did seem to suggest that it got
> lost between the exit from gdisplay's __init__ and the next call to the 
> class instance.
> One thing is that it does seem worse on machines that are a little tight 
> on memory.
> It is the one thing that does upset students a little with the visual 
> package, otherwise they seem to like it.
> 
> Roger.
> 

Re: [Visualpython-users] gdisplay objects seldom work

[Jonathan B. <jbr...@ea...>]

On Tue, 2003-09-30 at 08:49, Roger Fearick wrote:
> On Mon, 29 Sep 2003, Bruce Sherwood wrote:

> The result is a frozen window, usually displaying the minimum
> axes possible (i.e. the problem seems to lie in the creation of the
> window). 
> In general, related activity in a display window will continue.

Can you send me an example of this behavior?  All of the locks that I
have seen have locked all of the windows.  Sometimes there would be a
hiccup and the main window would jump, but the main window would never
keep rendering new frames when the other windows were frozen.

> I guess that this is related to threading and some deadlock. 

I think that the problem was that the Python thread and the rendering
thread were obtaining a pair of mutex locks in opposite order from each
other, creating a race condition to lock the second mutex and the
subsequent deadlock.

> I've
> tried to trace through the code and find whereabouts the stall
> is happening, but with little success - the usual problem with an
> intermittent fault! However, some tests did seem to suggest that it got
> lost between the exit from gdisplay's __init__ and the next call to the 
> class instance.
> One thing is that it does seem worse on machines that are a little tight 
> on memory.
> It is the one thing that does upset students a little with the visual 
> package, otherwise they seem to like it.
> 
> Roger.

I have a VPython script that consistently locked up my computers, and
now it runs fine with the Boostified version of VPython.  However, just
because I can't reproduce the bug anymore in this case doesn't mean it
isn't there.  I could use a few more people's eyes on this one.

I haven't written generic build scripts for any platform, but I can
e-mail a Windows binary to anyone that wants to help test this problem. 
The attachment would be a .5MB tar.gz file.  I can also work with anyone
who wants to build it on their Linux or Mac to help test this fix.

Thanks,
Jonathan Brandmeyer

Re: [Visualpython-users] gdisplay objects seldom work

[Gary P. <pa...@in...>]

----- Original Message ----- 
From: "Joe Heafner" <hea...@vn...>



> Hi.
>
> I'm running Mac OS X (10.2.6) and Visual 2.1.1 compiled from source.

ditto, except I have 2.1.somethingelse

> I'm still experiencing problems with gdisplay objects. If I create, for
> example, a graph with gcurve the program usually stalls upon execution,
> but no errors are indicated. Sometimes, roughly 90% of the time, both
> the main window and the graph window open up but the graph window is
> just blank and the other window, usually containing an animation of a
> physical system (e.g. oscillating spring-mass system) remains static.
> Sometimes, roughly 10% of the time, the graph shows up correctly, but
> NOT point by point. The entire graph is displayed after the animation
> is over, and the oscillating spring-mass never appears to move at all.
> On a very, very few occasions I get the correct output, which is an
> oscillating spring-mass system in one window and a graph updated in
> real time in the other window. However, I never ever get the program to
> work completely correctly twice in a row. Everything works fine when
> all the gdisplay related statements are commented out.

In my case the program never locks up, but it does stutter a bit, especially
when the animation first starts.  And I have seen the stutter be long enough
that the simulation is all but finished before the graphics start, and then
they're there all at once (as you described).   I've experimented with
placing a time.sleep(n) [where n is typically between 2 and 7]  at various
places.  I find that if I initialize the gdisplay window,  then
time.sleep(),  then start my "while" loop,  I don't lose any of the
animation.  Of course, there is a bit of a delay, and it's still a bit
jerky, but it works.  YMMV.

>
> Another issue is that when a program that uses a gdisplay object
> terminates, the only way to remove the open windows is to choose "End
> program" from inside IDLE. Otherwise, the output windows remain active
> and can only be removed by opening up an xterm, issuing "top", getting
> the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of
> the correct python22 process.

Yep.  But simply restarting the program (F5) kills the old windows and opens
new ones. At the end of the day, though, its "End Program".  Would "ps" be a
hair more convenient than "top"?

-gary

>
> Any ideas what's going on?
>
> Cheers,
> Joe Heafner
>
> -----
> New email address: hea...@ct...
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] gdisplay objects seldom work

[Jonathan B. <jbr...@ea...>]

On Mon, 2003-09-29 at 22:24, Gary Pajer wrote:
> ----- Original Message ----- 
> From: "Joe Heafner" <hea...@vn...>

> > I'm still experiencing problems with gdisplay objects. If I create, for
> > example, a graph with gcurve the program usually stalls upon execution,
> > but no errors are indicated. Sometimes, roughly 90% of the time, both
> > the main window and the graph window open up but the graph window is
> > just blank and the other window, usually containing an animation of a
> > physical system (e.g. oscillating spring-mass system) remains static.
> > Sometimes, roughly 10% of the time, the graph shows up correctly, but
> > NOT point by point. The entire graph is displayed after the animation
> > is over, and the oscillating spring-mass never appears to move at all.
> > On a very, very few occasions I get the correct output, which is an
> > oscillating spring-mass system in one window and a graph updated in
> > real time in the other window. However, I never ever get the program to
> > work completely correctly twice in a row. Everything works fine when
> > all the gdisplay related statements are commented out.
> 
> In my case the program never locks up, but it does stutter a bit, especially
> when the animation first starts.  And I have seen the stutter be long enough
> that the simulation is all but finished before the graphics start, and then
> they're there all at once (as you described).   I've experimented with
> placing a time.sleep(n) [where n is typically between 2 and 7]  at various
> places.  I find that if I initialize the gdisplay window,  then
> time.sleep(),  then start my "while" loop,  I don't lose any of the
> animation.  Of course, there is a bit of a delay, and it's still a bit
> jerky, but it works.  YMMV.


The worst part of this is that it is a probabilistic problem.  Sometimes
you will get a complete lock-up, sometimes just a stutter, sometimes
totally smooth operation.  All of this makes it *hard* to debug, but
most of the issues are resolved on the boostification branch, and can be
backported.

The most stressful case for me ended up being a program that produced
two graphs simultaneously while running a simulation, and that one runs
smoothly now.

Since we don't have anything in our demos that really exercises this
bug, can you submit a particularly damning test case to the online
bugtracker at Sourceforge?  I'll probably be adding one or two of my
own, but it always helps to have multiple people attacking probabilistic
bugs like this one.

> > Another issue is that when a program that uses a gdisplay object
> > terminates, the only way to remove the open windows is to choose "End
> > program" from inside IDLE. Otherwise, the output windows remain active
> > and can only be removed by opening up an xterm, issuing "top", getting
> > the PID, exiting "top", and issuing "kill xxx" where xxx is the pid of
> > the correct python22 process.
> 
> Yep.  But simply restarting the program (F5) kills the old windows and opens
> new ones. At the end of the day, though, its "End Program".  Would "ps" be a
> hair more convenient than "top"?
> 
> -gary

Unfortunately process termination still sucks for multiple windows.  I
have gotten it to work for the case where a simulation has ended and the
interpreter is waiting on you to close the windows, but not when you are
still running the simulation (or are running an infinite simulation).  I
have a couple of ideas that I can try in the next couple of days, but
the debugger isn't helping at all in this case.

Thanks for your reports,
-Jonathan Brandmeyer