Hi Chris: I've been trying this out on more platforms and I'm beginning
to think this is a problem with the X setup or graphics driver for my
Debian machine. I only see the crash when viewing from my Debian machine,
whether I'm running the TriD demo on a remote machine via exported X
connection or locally. I've tried compiling PDL with
POGL_WINDOW_TYPE => 'x11'
or
POGL_WINDOW_TYPE => 'glut'
both crash in the same way on my Debian box.
The CentOS machine I originally described does not have the problem if I
(1) log into it directly and run the demo or (2) if I export the X
connection to my Mac laptop and run the demo. In addition, when I install
PDL and OpenGL on the Mac and run it directly, there is no problem.
So, I'm still not sure how to track this down, but it may not be a problem
with the OpenGL module or with PDL::Graphics::TriD.
If anyone has any ideas on how to debug this I'd be appreciative!
Regards,
Doug
[email protected]
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
On Wed, 25 Apr 2012, chm wrote:
On 4/24/2012 7:04 PM, Doug Hunt wrote:
Hi Chris: Thanks for your time and information!
I've learned a few more things:
1) The original hang took place from my Debian wheezy/sid box:
Linux arcana 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:48:51 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
when I logged into the CentOS box exporting an X session. The CentOS
machine did not crash (thank fortune, it is one of our large servers...)
2) When I log into the console of the CentOS box, the TriD demo works fine.
3) When I do a fresh CPAN install of:
PDL (v2.4.10) and
OpenGL (v0.66)
on the Debian box, the same TriD crash occurs.
I don't know if a kernel dump would help--I can still log in remotely to
the Debian box. It is just that X is so blocked up I can't kill it.
I suspect that somehow glutSwapBuffers() is swapping from/into some bad
memory and things are getting corrupted.
Regards,
Doug
[email protected]
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611
I'm a bit confused. Now the CentOS is ok but debian crashes?
At any rate more data points is better. Unfortunately, the
fact that the problem happens at glutSwapBuffers() may not
be as meaningful as one could hope since at that point all the
OpenGL drawing stuff takes effect so the fail may not actually
be from the glutSwapBuffers() call but from something in the
drawing phase...
I found a CentOS VM that I could try. I may not get to it
until this weekend.
--Chris
On Tue, 24 Apr 2012, Chris Marshall wrote:
What do you get from the kernel dump? Here is a link
to some debugging ideas. Sorry, don't know if they are
relevant....
http://lists.centos.org/pipermail/centos/2009-June/077017.html
--Chris
On Tue, Apr 24, 2012 at 5:41 PM, Chris Marshall
<[email protected]> wrote:
Hi Doug-
I'm sorry to hear you have been "suffering in silence" for some years!
The latest open bug report for TriD is from 2006 and is just that the
perldl shell dies when you exit a window.
Please, open a ticket on our sf.net bug tracker with all the specific
information per the BUGS file in the PDL distribution. You should
probably include your X11 driver information since a hard
display+machine crash from graphics is a bug somewhere.
Also, I'm in the process of building a number of Virtualbox machines
for testing on so could you give me the details/links/versions so I
could try setting up a similar configuration to see if I can reproduce
the problem? Have you tried running the code on a CentOS VM?
As you might imagine there are a lot of places the problem could come
from: a CentOS bug, an X11/GLX bug, and OpenGL bug, a Perl OpenGL
binding bug, a TriD bug, cosmic rays,... :-)
--Chris
On Tue, Apr 24, 2012 at 4:18 PM, Doug Hunt <[email protected]> wrote:
Hi all: For some years now (ever since the switch of
PDL::Graphics::TriD to
POGL) I've been trying to get TriD working. The problem I have is
that on
running 'demo 3d' my machine crashes *hard*, necessitating a full power
cycle on the machine I'm running the X server on, even if I run
'demo 3d' on
a remote machine with an X window exported.
Needless to say, having to manually cycle the power between each
failure
makes the debug loop so long that I've not had the time to look into it
much.
In the past (before POGL) I was able to use PDL::Graphics::TriD for
some
nice orbit geometry visualizations--I'm trying to regain this
capability!
In my most recent attempt, I upgraded to the most recent perl, PDL
and POGL:
perl v5.15.9
PDL-2.4.10_003
OpenGL-0.66
I'm running on CentOS 5.8 (which is essentially RedHat Enterprise
Linux 5.8)
With the above setup, after several machine crashes and power cycles,
I'm able to determine that when running this script (the first demo):
--------------------------------------------------------------------
use PDL;
use PDL::Graphics::TriD;
use PDL::Graphics::TriD::Image;
# Number of subdivisions for lines / surfaces.
$size = 25;
$cz = (xvals zeroes $size+1) / $size; # interval 0..1
$cx = sin($cz*12.6); # Corkscrew
$cy = cos($cz*12.6);
line3d [$cx,$cy,$cz]; # Draw a line
--------------------------------------------------------------------
The lockup occurs in line3d at the call to glutSwapBuffers(); in GL.pm
line 939 (see the stack trace attached).
Before this, there is an error message:
--------------------------------------------------------------
libGL error: open DRM failed (Operation not permitted)
libGL error: reverting to (slow) indirect rendering
freeglut (trid.pl): Unable to create direct context rendering for
window
'GLUT TriD'
This may hurt performance.
--------------------------------------------------------------
This error message also occured when testing OpenGL-0.66, but did
not seem
to cause any problems.
Does anyone have any ideas of what might be wrong or how to track it
down?
I'd like to be able to use TriD, but have not been able to for at
least two
years under several versions of CentOS 4 and 5 on both 32 and 64 bit PC
architectures.
Any thoughts welcome!
Thanks,
Doug Hunt
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
