Great! Good luck with your visualizations. --Chris On Wed, Apr 25, 2012 at 6:02 PM, Doug Hunt <[email protected]> wrote: > Hi Chris: After a lot of fiddling and following the instructions for > debugging X server problems at: > > http://www.x.org/wiki/Development/Documentation/ServerDebugging > > I found a work-around. If I just add the -keeptty flag to the X invocation > on my machine (I should have said it is not a Debian machine but an Ubuntu > machine) then the TriD stuff works fine. Odd. > > It is an interesting exercise to modify the Ubuntu start-up scripts to add a > new switch to the X server. Difficult to describe in few words. > > Thanks for all your help and ideas! > > > Regards, > > Doug > > > [email protected] > Software Engineer > UCAR - COSMIC, Tel. (303) 497-2611 > > On Wed, 25 Apr 2012, Chris Marshall wrote: > >> 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
