[Perldl] PDL::Graphics::TriD causes hard crash on Linux

chm devel.chm.01 at gmail.com
Tue Apr 24 18:54:44 HST 2012


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
>
> dhunt at ucar.edu
> 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
>> <devel.chm.01 at gmail.com> 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 <dhunt at ucar.edu> 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




More information about the Perldl mailing list