Doug- You could always try building PDL-2.4.5 with USE_POGL=>0 and see if you still have a problem. It is a system problem if X is hanging or crashing from a user program, but... if we are doing something not quite right in TriD or POGL I'm happy to fix that.
--Chris On Wed, Apr 25, 2012 at 4:00 PM, Doug Hunt <[email protected]> wrote: > 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
