Mayavi offscreen rendering

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Mayavi offscreen rendering

Geoffrey Ely
Hi,

Is Mayavi offscreen rendering known to work under Snow Leopard? This causes a bus error for me:

from enthought.mayavi import mlab
mlab.options.offscreen = True
mlab.figure()

Python version is: Python 2.6.4 |EPD 6.1-1 (32-bit)| (r264:75706, Dec 11 2009, 10:58:54).
VTK is one provided by EPD.

A few clues from the crash report:
OS Version:      Mac OS X 10.6.2 (10C540)
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000507
0   libvtkRendering.5.4.dylib     0x1e27123a vtkOpenGLExtensionManager::ReadOpenGLExtensions() + 584

The following does not crash:
fig = mlab.figure()
fig.scene.off_screen_rendering = True

But then I have created a window, which I was hoping to avoid.

Thanks,
Geoff
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Erik Tollerud
I've encountered almost exactly the same problem on Ubuntu (9.10,
although it was also present in 9.04).  When I do your first example I
get a segmentation fault (which I believe is pretty much the same as a
bus error - null pointers or whatever), and the second one works.
Python is 2.6.4, latest ETS, and VTK is 5.4.0

On Sun, Mar 28, 2010 at 10:40 AM, Geoffrey Ely <[hidden email]> wrote:

> Hi,
>
> Is Mayavi offscreen rendering known to work under Snow Leopard? This causes a bus error for me:
>
> from enthought.mayavi import mlab
> mlab.options.offscreen = True
> mlab.figure()
>
> Python version is: Python 2.6.4 |EPD 6.1-1 (32-bit)| (r264:75706, Dec 11 2009, 10:58:54).
> VTK is one provided by EPD.
>
> A few clues from the crash report:
> OS Version:      Mac OS X 10.6.2 (10C540)
> Exception Type:  EXC_BAD_ACCESS (SIGBUS)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000507
> 0   libvtkRendering.5.4.dylib           0x1e27123a vtkOpenGLExtensionManager::ReadOpenGLExtensions() + 584
>
> The following does not crash:
> fig = mlab.figure()
> fig.scene.off_screen_rendering = True
>
> But then I have created a window, which I was hoping to avoid.
>
> Thanks,
> Geoff
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
On Tue, Mar 30, 2010 at 03:28:23PM -0700, Erik Tollerud wrote:
> I've encountered almost exactly the same problem on Ubuntu (9.10,
> although it was also present in 9.04).  When I do your first example I
> get a segmentation fault (which I believe is pretty much the same as a
> bus error - null pointers or whatever), and the second one works.
> Python is 2.6.4, latest ETS, and VTK is 5.4.0

> > Is Mayavi offscreen rendering known to work under Snow Leopard? This causes a bus error for me:

> > from enthought.mayavi import mlab
> > mlab.options.offscreen = True
> > mlab.figure()

Under Ubuntu (9.04), I don't get a segfault, using ETS SVN.

I don't really see what recent change could have caused a segfault. I
believe the reason of the crash may be found in a difference in our
setups. I actually suspect a graphics-card issue (we have so many).
What's your graphics card?

Also, could you run the above code in gdb. Simply create a 'tmp.py' file
with the code, and do:

resting ~ $ gdb python
[18:35]
GNU gdb (GDB) 7.0-ubuntu
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...Reading symbols from
/usr/lib/debug/usr/bin/python2.6...done.
(no debugging symbols found)...done.
(gdb) run tmp.py
Starting program: /usr/bin/python tmp.py

This will probably help narrowing the cause of the segfault.

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
In reply to this post by Geoffrey Ely
Hi Geoffrey

On Sun, Mar 28, 2010 at 10:40:38AM -0700, Geoffrey Ely wrote:
> Is Mayavi offscreen rendering known to work under Snow Leopard? This causes a bus error for me:

I am sorry to hear that. This should work (although they are many reasons
why it may fail).

> from enthought.mayavi import mlab
> mlab.options.offscreen = True
> mlab.figure()

> Python version is: Python 2.6.4 |EPD 6.1-1 (32-bit)| (r264:75706, Dec 11 2009, 10:58:54).
> VTK is one provided by EPD.

> A few clues from the crash report:
> OS Version:      Mac OS X 10.6.2 (10C540)
> Exception Type:  EXC_BAD_ACCESS (SIGBUS)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000507
> 0   libvtkRendering.5.4.dylib     0x1e27123a vtkOpenGLExtensionManager::ReadOpenGLExtensions() + 584

Ok, so we are getting a segfault in VTK. Can other people confirm/infirm
that they can run VTK in offscreen mode on EPD and or OSX.

I suspect that this is a VTK problem, but it might be due to how we
initialise the render window. Also, it would be nice to try and find a
workaround.

Cheers,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Erik Tollerud
In reply to this post by Gael Varoquaux
Aha!  I didn't realize I would get more information running
interactively in gdb as compared to what comes out from a core dump.
Anyway, the first 10 frames of the stack trace are below (the rest of
the frames all seem to be in PyEval or PyObject functions, so
presumably they aren't useful).  It's not obvious to me what could be
wrong in the ReadOpenGLExtensions function, but that does seem to be
the source of the problem...

Graphics card is a nVidia 8600M GT... I'm running the latest release
drivers, although I've encountered this problem for many driver
versions now.  I have another Ubuntu 9.04 box that I can test this on
with a Geforce 200-series card... I *think* I had the same problem on
that computer, but I don't remember for sure and will test it when I
next get a chance.

Underneath the Ubuntu stack trace, I've included an an error log from
an OS X 10.6 machine with EPD 6.1. I ran the same file and I get a Bus
Error, and it seems to start in the same place
(ReadOpenGLExtensions)... This one is on a Mac Mini (with GeForce
9400M).


Ubuntu 9.04 latest ETS, GeForce 8600M GT:

#0  0x063bc392 in vtkOpenGLExtensionManager::ReadOpenGLExtensions() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#1  0x063bb54b in vtkOpenGLExtensionManager::Update() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#2  0x063bb588 in vtkOpenGLExtensionManager::ExtensionSupported(char const*) ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#3  0x063e4d0e in
vtkOpenGLRenderWindow::CreateHardwareOffScreenWindow(int, int) () from
/usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#4  0x06427ac6 in vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#5  0x064284ac in vtkXOpenGLRenderWindow::Initialize() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#6  0x0642879e in vtkXOpenGLRenderWindow::Start() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#7  0x063a504a in vtkXRenderWindowInteractor::Initialize() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#8  0x05f474c1 in PyvtkXRenderWindowInteractor_Initialize(_object*, _object*)
    () from /usr/local/lib/vtk-5.4/libvtkRenderingPythonD.so.5.4
#9  0x080dc0d0 in call_function (f=0xba4ab84, throwflag=0)
    at ../Python/ceval.c:3706
#10 PyEval_EvalFrameEx (f=0xba4ab84, throwflag=0) at ../Python/ceval.c:2389


OS X 10.6 EPD 6.1,GeForce 9400M:

0   libvtkRendering.5.4.dylib     0x1dcb123a
vtkOpenGLExtensionManager::ReadOpenGLExtensions() + 584
1   org.python.python             0x000c0c16 PyEval_EvalFrameEx + 21862
2   org.python.python             0x000c0c16 PyEval_EvalFrameEx + 21862
3   org.python.python             0x000c240d PyEval_EvalCodeEx + 2109
4   org.python.python             0x0003f8b6 function_call + 166
5   org.python.python             0x0000ef35 PyObject_Call + 85
6   org.python.python             0x00020d36 instancemethod_call + 422
7   org.python.python             0x0000ef35 PyObject_Call + 85
8   org.python.python             0x000759d7 slot_tp_init + 87
9   org.python.python             0x00074400 type_call + 176
10  org.python.python             0x0000ef35 PyObject_Call + 85
11  org.python.python             0x000be05c PyEval_EvalFrameEx + 10668
12  org.python.python             0x000c240d PyEval_EvalCodeEx + 2109
13  org.python.python             0x0003f8b6 function_call + 166
14  org.python.python             0x0000ef35 PyObject_Call + 85
15  org.python.python             0x00020d36 instancemethod_call + 422
16  org.python.python             0x0000ef35 PyObject_Call + 85
17  org.python.python             0x000759d7 slot_tp_init + 87
18  org.python.python             0x00074400 type_call + 176
19  org.python.python             0x0000ef35 PyObject_Call + 85
20  org.python.python             0x000bebe7 PyEval_EvalFrameEx + 13623
21  org.python.python             0x000c240d PyEval_EvalCodeEx + 2109
22  org.python.python             0x0003f8b6 function_call + 166
23  org.python.python             0x0000ef35 PyObject_Call + 85
24  org.python.python             0x000be05c PyEval_EvalFrameEx + 10668
25  org.python.python             0x000c240d PyEval_EvalCodeEx + 2109
26  org.python.python             0x0003f8b6 function_call + 166
27  org.python.python             0x0000ef35 PyObject_Call + 85
28  org.python.python             0x000be05c PyEval_EvalFrameEx + 10668
29  org.python.python             0x000c240d PyEval_EvalCodeEx + 2109
30  org.python.python             0x000c047c PyEval_EvalFrameEx + 19916
31  org.python.python             0x000c240d PyEval_EvalCodeEx + 2109
32  org.python.python             0x000c047c PyEval_EvalFrameEx + 19916
33  org.python.python             0x000c240d PyEval_EvalCodeEx + 2109
34  org.python.python             0x000c2527 PyEval_EvalCode + 87
35  org.python.python             0x000e71e8 PyRun_FileExFlags + 168
36  org.python.python             0x000e80d3 PyRun_SimpleFileExFlags + 867
37  org.python.python             0x000f9d18 Py_Main + 3528
38  org.python.python             0x00001fb6 0x1000 + 4022

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             0x96ea60ea kevent + 10
1   libSystem.B.dylib             0x96ea6804 _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             0x96ea5cc3 _dispatch_queue_invoke + 163
3   libSystem.B.dylib             0x96ea5a68 _dispatch_worker_thread2 + 234
4   libSystem.B.dylib             0x96ea54f1 _pthread_wqthread + 390
5   libSystem.B.dylib             0x96ea5336 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib             0x96ea5182 __workq_kernreturn + 10
1   libSystem.B.dylib             0x96ea5718 _pthread_wqthread + 941
2   libSystem.B.dylib             0x96ea5336 start_wqthread + 30




On Sat, Apr 3, 2010 at 9:41 AM, Gael Varoquaux
<[hidden email]> wrote:

> On Tue, Mar 30, 2010 at 03:28:23PM -0700, Erik Tollerud wrote:
>> I've encountered almost exactly the same problem on Ubuntu (9.10,
>> although it was also present in 9.04).  When I do your first example I
>> get a segmentation fault (which I believe is pretty much the same as a
>> bus error - null pointers or whatever), and the second one works.
>> Python is 2.6.4, latest ETS, and VTK is 5.4.0
>
>> > Is Mayavi offscreen rendering known to work under Snow Leopard? This causes a bus error for me:
>
>> > from enthought.mayavi import mlab
>> > mlab.options.offscreen = True
>> > mlab.figure()
>
> Under Ubuntu (9.04), I don't get a segfault, using ETS SVN.
>
> I don't really see what recent change could have caused a segfault. I
> believe the reason of the crash may be found in a difference in our
> setups. I actually suspect a graphics-card issue (we have so many).
> What's your graphics card?
>
> Also, could you run the above code in gdb. Simply create a 'tmp.py' file
> with the code, and do:
>
> resting ~ $ gdb python
> [18:35]
> GNU gdb (GDB) 7.0-ubuntu
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "i486-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/bin/python...Reading symbols from
> /usr/lib/debug/usr/bin/python2.6...done.
> (no debugging symbols found)...done.
> (gdb) run tmp.py
> Starting program: /usr/bin/python tmp.py
>
> This will probably help narrowing the cause of the segfault.
>
> Gaël
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
On Mon, Apr 05, 2010 at 11:23:27AM -0700, Erik Tollerud wrote:
> Aha!  I didn't realize I would get more information running
> interactively in gdb as compared to what comes out from a core dump.
> Anyway, the first 10 frames of the stack trace are below (the rest of
> the frames all seem to be in PyEval or PyObject functions, so
> presumably they aren't useful).

Actually, they are, but you need to inspect them using 'pyframe', and the
.gdbinit I sent you. That will tell us where, in Python, the segfault is
happening. However, I suspect that it is not terribly relevent to our
problem here.

> It's not obvious to me what could be wrong in the ReadOpenGLExtensions
> function, but that does seem to be the source of the problem...

Agreed. It's slightly annoying, because I don't really see what could
trigger a segfault there other than a bug in X/graphics card drivers/VTK,
but I don't see why offscreen mode would trigger it.

> Graphics card is a nVidia 8600M GT... I'm running the latest release
> drivers, although I've encountered this problem for many driver
> versions now.  I have another Ubuntu 9.04 box that I can test this on
> with a Geforce 200-series card... I *think* I had the same problem on
> that computer, but I don't remember for sure and will test it when I
> next get a chance.

That would be helpful.

> Underneath the Ubuntu stack trace, I've included an an error log from
> an OS X 10.6 machine with EPD 6.1. I ran the same file and I get a Bus
> Error, and it seems to start in the same place
> (ReadOpenGLExtensions)... This one is on a Mac Mini (with GeForce
> 9400M).

OK, should think/play with code. It would be nice if I could reproduce on
one of my boxes...

This problem might have to wait for a while, as I am getting into really
stormy weather with regards to my schedule.

Cheers,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Erik Tollerud
On Mon, Apr 5, 2010 at 2:32 PM, Gael Varoquaux
<[hidden email]> wrote:

> On Mon, Apr 05, 2010 at 11:23:27AM -0700, Erik Tollerud wrote:
>> Aha!  I didn't realize I would get more information running
>> interactively in gdb as compared to what comes out from a core dump.
>> Anyway, the first 10 frames of the stack trace are below (the rest of
>> the frames all seem to be in PyEval or PyObject functions, so
>> presumably they aren't useful).
>
> Actually, they are, but you need to inspect them using 'pyframe', and the
> .gdbinit I sent you. That will tell us where, in Python, the segfault is
> happening. However, I suspect that it is not terribly relevent to our
> problem here.

Hmm... I tried it on a core dump file and it complained about missing
debugging symbols and I think even the pyframe was having problems...
but I admit I didn't try very hard - next time I have a problem like
this I can explore a bit further - thanks for the tip!

> Agreed. It's slightly annoying, because I don't really see what could
> trigger a segfault there other than a bug in X/graphics card drivers/VTK,
> but I don't see why offscreen mode would trigger it.

Yes that does indeed seem very odd... Does
fig.scene.off_screen_rendering = True use some different OpenGL
Extension?  If it's using the same one it's even odder that it doesn't
seem to trigger the segfault.

>> Graphics card is a nVidia 8600M GT... I'm running the latest release
>> drivers, although I've encountered this problem for many driver
>> versions now.  I have another Ubuntu 9.04 box that I can test this on
>> with a Geforce 200-series card... I *think* I had the same problem on
>> that computer, but I don't remember for sure and will test it when I
>> next get a chance.
>
> That would be helpful.

Unfortunately, it appears some problem is preventing that particular
computer from booting into Ubuntu (I suppose I shouldn't be surprised
- I installed it with the very first alpha of 9.10...).  When I have
some time to sit down and work through it I'll try installing 10.04
(which is at least in beta... better than alpha anyway) and see if the
problem is still there.  That has the added advantage of also allowing
me to try the nouveau drivers and see if the problem is present in
them as well as the proprietary nVidia drivers. I'll repost here
whenever I get around to trying that.
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
Hey Erik,

On Mon, Apr 12, 2010 at 11:53:55PM -0700, Erik Tollerud wrote:
> On Mon, Apr 5, 2010 at 2:32 PM, Gael Varoquaux
> <[hidden email]> wrote:
> > On Mon, Apr 05, 2010 at 11:23:27AM -0700, Erik Tollerud wrote:
> >> Aha!  I didn't realize I would get more information running
> >> interactively in gdb as compared to what comes out from a core dump.
> >> Anyway, the first 10 frames of the stack trace are below (the rest of
> >> the frames all seem to be in PyEval or PyObject functions, so
> >> presumably they aren't useful).

> > Actually, they are, but you need to inspect them using 'pyframe', and the
> > .gdbinit I sent you. That will tell us where, in Python, the segfault is
> > happening. However, I suspect that it is not terribly relevent to our
> > problem here.

> Hmm... I tried it on a core dump file and it complained about missing
> debugging symbols and I think even the pyframe was having problems...
> but I admit I didn't try very hard - next time I have a problem like
> this I can explore a bit further - thanks for the tip!

That trick will work only in a live gdb session with the program still in
memory.

> > Agreed. It's slightly annoying, because I don't really see what could
> > trigger a segfault there other than a bug in X/graphics card drivers/VTK,
> > but I don't see why offscreen mode would trigger it.

> Yes that does indeed seem very odd... Does
> fig.scene.off_screen_rendering = True use some different OpenGL
> Extension?  If it's using the same one it's even odder that it doesn't
> seem to trigger the segfault.

I've been thinking of it, and I think we encountered a similar problem a
while ago with fullscreen mode. Of course, I can't seem to find the
corresponding commit... However, looking at
enthought/tvtk/pyface/ui/wx/scence.py I remember a bit what the issue
was: when we use the off-screen rendering engine, we use a special
window, that we set to a very small size
(enthought/tvtk/pyface/tvtk_scene:TVTKWindow). That window uses the VTK
native event loop, rather than the toolkit event loop (a render window
needs a GL canvas, which come with an event loop). A while ago I believe
that we were using that same event loop for fullscreen, and it was
triggering segfaults when running within the wx event loop. We have now
switched to using the wx event loop in this case (see
enthought/tvtk/pyface/ui/wx/scene.py).

So, I am wondering if the segfault is not due to a conflicts created by
the presence of the wx and the VTK event loops. To help me diagnose this
(since I can't reproduce the problem) it would be great if someone who
has the problem could:

    * See if the segfault happens for the qt backend (do
      'export ETS_TOOLKIT=qt4' before starting your Python instance).

    * See if the segfault happens if wx is loaded but the event loop not
      started.

Thanks,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Erik Tollerud
Ok,

These tests are under Ubuntu 9.10 w/ GeForce 8600M

> So, I am wondering if the segfault is not due to a conflicts created by
> the presence of the wx and the VTK event loops. To help me diagnose this
> (since I can't reproduce the problem) it would be great if someone who
> has the problem could:

>    * See if the segfault happens for the qt backend (do
>      'export ETS_TOOLKIT=qt4' before starting your Python instance).

Done - segfault still appears, with the backtrace included below -
ReadOpenGLExtensions still seems to be the source of the problem.


>    * See if the segfault happens if wx is loaded but the event loop not
>      started.

I'm not sure exactly what you mean here... do you mean I should
"import wx" and "wx.App()" before any of the traits stuff is imported?
 That doesn't seem to have any effect...


Here's the segfault backtrace for qt4:

#0  0x069b9392 in vtkOpenGLExtensionManager::ReadOpenGLExtensions() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#1  0x069b854b in vtkOpenGLExtensionManager::Update() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#2  0x069b8588 in vtkOpenGLExtensionManager::ExtensionSupported(char const*) ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#3  0x069e1d0e in
vtkOpenGLRenderWindow::CreateHardwareOffScreenWindow(int, int) () from
/usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#4  0x06a24ac6 in vtkXOpenGLRenderWindow::CreateOffScreenWindow(int, int) ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#5  0x06a254ac in vtkXOpenGLRenderWindow::Initialize() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#6  0x06a2579e in vtkXOpenGLRenderWindow::Start() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#7  0x069a204a in vtkXRenderWindowInteractor::Initialize() ()
   from /usr/local/lib/vtk-5.4/libvtkRendering.so.5.4
#8  0x065444c1 in PyvtkXRenderWindowInteractor_Initialize(_object*, _object*)
    () from /usr/local/lib/vtk-5.4/libvtkRenderingPythonD.so.5.4
#9  0x080dc0d0 in call_function (f=0xb3feb44, throwflag=0)
    at ../Python/ceval.c:3706
#10 PyEval_EvalFrameEx (f=0xb3feb44, throwflag=0) at ../Python/ceval.c:2389
#11 0x080dd384 in fast_function (f=0xb3fb884, throwflag=0)
    at ../Python/ceval.c:3792
---Type <return> to continue, or q <return> to quit---
#12 call_function (f=0xb3fb884, throwflag=0) at ../Python/ceval.c:3727
#13 PyEval_EvalFrameEx (f=0xb3fb884, throwflag=0) at ../Python/ceval.c:2389
#14 0x080dd384 in fast_function (f=0xb3f71ec, throwflag=0)
    at ../Python/ceval.c:3792
#15 call_function (f=0xb3f71ec, throwflag=0) at ../Python/ceval.c:3727
#16 PyEval_EvalFrameEx (f=0xb3f71ec, throwflag=0) at ../Python/ceval.c:2389
#17 0x080dddf2 in PyEval_EvalCodeEx (co=0x9119b18, globals=0x911c0b4,
    locals=0x0, args=0xb3cbf38, argcount=1, kws=0x98ddfb0, kwcount=1,
    defs=0x93ce918, defcount=1, closure=0x0) at ../Python/ceval.c:2968
#18 0x0816022f in function_call (func=0x95fcfb4, arg=0xb3cbf2c, kw=0xb3d2714)
    at ../Objects/funcobject.c:524
#19 0x0806120a in PyObject_Call (func=0x95fcfb4, arg=0xb3cbf2c, kw=0xb3d2714)
    at ../Objects/abstract.c:2492
#20 0x080684ac in instancemethod_call (func=0xb357874, arg=0xb3cbf2c,
    kw=0xb3d2714) at ../Objects/classobject.c:2579
#21 0x0806120a in PyObject_Call (func=0xb357874, arg=0xb7f9902c, kw=0xb3d2714)
    at ../Objects/abstract.c:2492
#22 0x080aea8e in slot_tp_init (self=0xb7e9ad1c, args=0xb7f9902c,
    kwds=0xb3d2714) at ../Objects/typeobject.c:5638
#23 0x080aa165 in type_call (type=0x94cdb5c, args=0xb7f9902c, kwds=0xb3d2714)
    at ../Objects/typeobject.c:747
#24 0x0806120a in PyObject_Call (func=0x94cdb5c, arg=0xb7f9902c, kw=0xb3d2714)
    at ../Objects/abstract.c:2492
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
On Wed, Apr 14, 2010 at 01:36:12PM -0700, Erik Tollerud wrote:
> >    * See if the segfault happens for the qt backend (do
> >      'export ETS_TOOLKIT=qt4' before starting your Python instance).

> Done - segfault still appears, with the backtrace included below -
> ReadOpenGLExtensions still seems to be the source of the problem.

OK. Interesting. It sort of contradicts my theory.

One of my colleagues personnal laptop is displaying a similar problem,
I'll try to borrow it a week end, and hack on it to solve the problem.

Cheers,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Erik Tollerud
Just to add a little more mystery, the problem is *not* present under
the Ubuntu 10.4 beta 2 on a nVidia GTX 275 using the Ubuntu mayavi
package (it appears to be 3.3.0)... either of the two examples seem to
work without any problems...  But good luck trying to trick it down
with your colleague's laptop!

On a probably unrelated note, though, I see the following exception if
I do mlab.savefig('test.png') on the above setup with
mlab.options.offscreen set to True (and it works fine if its False):

enthought.traits.trait_errors.TraitError: The 'magnification' trait of
a TVTKScene instance must be 1 <= an integer <= 2048, but a value of 2
<type 'numpy.int64'> was specified.

This is of course a problem given that my primary use-case is for
generating frames of a movie in the background while I go do something
else.

On Wed, Apr 14, 2010 at 1:56 PM, Gael Varoquaux
<[hidden email]> wrote:

> On Wed, Apr 14, 2010 at 01:36:12PM -0700, Erik Tollerud wrote:
>> >    * See if the segfault happens for the qt backend (do
>> >      'export ETS_TOOLKIT=qt4' before starting your Python instance).
>
>> Done - segfault still appears, with the backtrace included below -
>> ReadOpenGLExtensions still seems to be the source of the problem.
>
> OK. Interesting. It sort of contradicts my theory.
>
> One of my colleagues personnal laptop is displaying a similar problem,
> I'll try to borrow it a week end, and hack on it to solve the problem.
>
> Cheers,
>
> Gaël
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
On Thu, Apr 15, 2010 at 02:51:21AM -0700, Erik Tollerud wrote:
> Just to add a little more mystery, the problem is *not* present under
> the Ubuntu 10.4 beta 2 on a nVidia GTX 275 using the Ubuntu mayavi
> package (it appears to be 3.3.0)... either of the two examples seem to
> work without any problems...  But good luck trying to trick it down
> with your colleague's laptop!

Wait, you are saying that changing the mayavi version changes the bug, or
changing the driver version sorts the problem out?

> On a probably unrelated note, though, I see the following exception if
> I do mlab.savefig('test.png') on the above setup with
> mlab.options.offscreen set to True (and it works fine if its False):

> enthought.traits.trait_errors.TraitError: The 'magnification' trait of
> a TVTKScene instance must be 1 <= an integer <= 2048, but a value of 2
> <type 'numpy.int64'> was specified.

OK, that's easy to solve: just cast to an int in the mlab.savefig code.
I'll do a patch ASAP, but I am at a conference right now, so it might
take a bit of time. You should be able to fix this easily by yourself to
get you out of trouble.

Cheers,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Erik Tollerud
> On Thu, Apr 15, 2010 at 02:51:21AM -0700, Erik Tollerud wrote:
>> Just to add a little more mystery, the problem is *not* present under
>> the Ubuntu 10.4 beta 2 on a nVidia GTX 275 using the Ubuntu mayavi
>> package (it appears to be 3.3.0)... either of the two examples seem to
>> work without any problems...  But good luck trying to trick it down
>> with your colleague's laptop!
>
> Wait, you are saying that changing the mayavi version changes the bug, or
> changing the driver version sorts the problem out?

Well, I'm pretty sure the mayavi version isn't it (at least, not
exclusively), because the problem occurred on my laptop before I
upgraded to 3.3.1 ... It's also probably not a VTK version problem -
the Lucid VTK version is apparently still 5.2, and I'm facing the
problem in my 5.4 install.  And the segfault still happened on my
laptop when I had 5.2 installed, so it's not a regression in 5.4
either.

I'm also using the exact same nVidia driver on my laptop as on the
desktop - I haven't yet tested nouveau, but I'm fairly sure now that
it does NOT have 3D acceleration currently, so it will likely not work
at all.


> OK, that's easy to solve: just cast to an int in the mlab.savefig code.
> I'll do a patch ASAP, but I am at a conference right now, so it might
> take a bit of time. You should be able to fix this easily by yourself to
> get you out of trouble.

Ah, yes, I see now that savefig itself sets the magnification - I'm a
bit confused as to why it only happens when offscreen is enabled, but
I guess it doesn't really matter. Thanks!
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
On Thu, Apr 15, 2010 at 01:27:14PM -0700, Erik Tollerud wrote:
> Well, I'm pretty sure the mayavi version isn't it (at least, not
> exclusively), because the problem occurred on my laptop before I
> upgraded to 3.3.1 ... It's also probably not a VTK version problem -
> the Lucid VTK version is apparently still 5.2, and I'm facing the
> problem in my 5.4 install.  And the segfault still happened on my
> laptop when I had 5.2 installed, so it's not a regression in 5.4
> either.

OK, not mayavi and not VTK.

> I'm also using the exact same nVidia driver on my laptop as on the
> desktop - I haven't yet tested nouveau, but I'm fairly sure now that
> it does NOT have 3D acceleration currently, so it will likely not work
> at all.

OK, so both computer do display the bug right? (I am a bit lost: doing
too many things together). This seems to be clearly pointing in the
direction of the graphics driver as the cuplrit, unfortunately, we have
to live with it, and try to work around the problem.

> > OK, that's easy to solve: just cast to an int in the mlab.savefig code.
> > I'll do a patch ASAP, but I am at a conference right now, so it might
> > take a bit of time. You should be able to fix this easily by yourself to
> > get you out of trouble.

> Ah, yes, I see now that savefig itself sets the magnification - I'm a
> bit confused as to why it only happens when offscreen is enabled, but
> I guess it doesn't really matter. Thanks!

I believe that I had fixed that problem: when I look at the savefig code
in trunk, I see explicite casts to an int for every magnification
setting:
https://svn.enthought.com/enthought/browser/Mayavi/trunk/enthought/mayavi/tools/figure.py

Is this the version that you have? If not, would you mind trying it out
to see if it helps?

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Delegation problem with child class

Christophe Grimault
In reply to this post by Gael Varoquaux
Hi all,

I've got the following problem and no work around ! I have a traited
class RadioNetwork. It has several children TDMA, GTDMA, ...

I also have a class TxNode, that has an traited attribute radio_network,
instance of RadioNetwork, to which it Delegates some attributes.

At run time, when I create my node, something like :

>> tx_node.radio_network = self

where self is a GTDMA instance, I get :


   File "radionetwork.py", line 385, in __call__
    self._create_nodes()
  File "radionetwork.py", line 215, in _create_nodes
    tx_node.radio_network = self
  File
"/usr/lib/python2.6/site-packages/Traits-3.2.0-py2.6-linux-i686.egg/enthought/traits/trait_handlers.py", line 175, in error
    value )
enthought.traits.trait_errors.TraitError: The 'radio_network' trait of a
TxNode instance must be a RadioNetwork or None, but a value of
<__main__.GTDMA object at 0xad1ae9c> <class '__main__.GTDMA'> was
specified.

Any help ? I thought that Instance would allow a child instance, since a
child instance is also an instance of its parent class ?

Thanks in advance,

Chris




_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Erik Tollerud
In reply to this post by Gael Varoquaux
> OK, so both computer do display the bug right? (I am a bit lost: doing
> too many things together). This seems to be clearly pointing in the
> direction of the graphics driver as the cuplrit, unfortunately, we have
> to live with it, and try to work around the problem.

Sorry, this is indeed getting confusing - let me summarize:

* Snow Leopard w/ GeForce 9400M : bus error
* Ubuntu 9.10 w/ GeForce 8600M: segfault
* Ubuntu 10.04 beta w/ GeForce GTX 275: sucessful

So it does indeed suggest a driver problem in some sense, but it must
be a very strange corner case (hence possibly work-aroundable?) to
have been missed for nVidia cards all the way back to the 8000-series.

> I believe that I had fixed that problem: when I look at the savefig code
> in trunk, I see explicite casts to an int for every magnification
> setting:
> https://svn.enthought.com/enthought/browser/Mayavi/trunk/enthought/mayavi/tools/figure.py
>
> Is this the version that you have? If not, would you mind trying it out
> to see if it helps?

The version at that link is indeed the version I have, but it does
*not* appear to have an explicit cast on line 246, and if I change
mine
-        figure.scene.magnification = magnification
+        figure.scene.magnification = int(magnification)

It now works fine...
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Mayavi offscreen rendering

Gael Varoquaux
On Fri, Apr 16, 2010 at 09:06:24AM -0700, Erik Tollerud wrote:
> Sorry, this is indeed getting confusing - let me summarize:

> * Snow Leopard w/ GeForce 9400M : bus error
> * Ubuntu 9.10 w/ GeForce 8600M: segfault
> * Ubuntu 10.04 beta w/ GeForce GTX 275: sucessful

> So it does indeed suggest a driver problem in some sense, but it must
> be a very strange corner case (hence possibly work-aroundable?) to
> have been missed for nVidia cards all the way back to the 8000-series.

OK, I concour, and I agree that it might be work-aroundable. I'll look at
it when I find time.

> > I believe that I had fixed that problem: when I look at the savefig code
> > in trunk, I see explicite casts to an int for every magnification
> > setting:
> > https://svn.enthought.com/enthought/browser/Mayavi/trunk/enthought/mayavi/tools/figure.py

> > Is this the version that you have? If not, would you mind trying it out
> > to see if it helps?

> The version at that link is indeed the version I have, but it does
> *not* appear to have an explicit cast on line 246, and if I change
> mine
> -        figure.scene.magnification = magnification
> +        figure.scene.magnification = int(magnification)

Damn it. I had this fixed, on my box, but I forgot to commit it. Thanks a
lot for pointing this out, I just committed it.

Cheers,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation problem with child class

bryce hendrix-2
In reply to this post by Christophe Grimault
On 04/16/2010 09:43 AM, Christophe Grimault wrote:

> Hi all,
>
> I've got the following problem and no work around ! I have a traited
> class RadioNetwork. It has several children TDMA, GTDMA, ...
>
> I also have a class TxNode, that has an traited attribute radio_network,
> instance of RadioNetwork, to which it Delegates some attributes.
>
> At run time, when I create my node, something like :
>
>    
>>> tx_node.radio_network = self
>>>        
> where self is a GTDMA instance, I get :
>
>
>     File "radionetwork.py", line 385, in __call__
>      self._create_nodes()
>    File "radionetwork.py", line 215, in _create_nodes
>      tx_node.radio_network = self
>    File
> "/usr/lib/python2.6/site-packages/Traits-3.2.0-py2.6-linux-i686.egg/enthought/traits/trait_handlers.py", line 175, in error
>      value )
> enthought.traits.trait_errors.TraitError: The 'radio_network' trait of a
> TxNode instance must be a RadioNetwork or None, but a value of
> <__main__.GTDMA object at 0xad1ae9c>  <class '__main__.GTDMA'>  was
> specified.
>
> Any help ? I thought that Instance would allow a child instance, since a
> child instance is also an instance of its parent class ?
>
>    

Sure, you should be able to. My guess is some trait isn't defined
correctly. Are you able to post the code which exhibits the error?

Bryce

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Delegation problem with child class

Christophe Grimault
Thanks for answering,

but I finally found the problem. Everything was OK, but I had to create
a __main__ script outside of the file declaring a RadioNetwork class. By
doing this, __main__.GTDMA instance becomes RadioNetwork.GTDMA instance
and it's OK.

However, I don't know why ...

Regards

Chris

On Tue, 2010-04-20 at 14:54 -0500, bryce hendrix wrote:

> On 04/16/2010 09:43 AM, Christophe Grimault wrote:
> > Hi all,
> >
> > I've got the following problem and no work around ! I have a traited
> > class RadioNetwork. It has several children TDMA, GTDMA, ...
> >
> > I also have a class TxNode, that has an traited attribute radio_network,
> > instance of RadioNetwork, to which it Delegates some attributes.
> >
> > At run time, when I create my node, something like :
> >
> >    
> >>> tx_node.radio_network = self
> >>>        
> > where self is a GTDMA instance, I get :
> >
> >
> >     File "radionetwork.py", line 385, in __call__
> >      self._create_nodes()
> >    File "radionetwork.py", line 215, in _create_nodes
> >      tx_node.radio_network = self
> >    File
> > "/usr/lib/python2.6/site-packages/Traits-3.2.0-py2.6-linux-i686.egg/enthought/traits/trait_handlers.py", line 175, in error
> >      value )
> > enthought.traits.trait_errors.TraitError: The 'radio_network' trait of a
> > TxNode instance must be a RadioNetwork or None, but a value of
> > <__main__.GTDMA object at 0xad1ae9c>  <class '__main__.GTDMA'>  was
> > specified.
> >
> > Any help ? I thought that Instance would allow a child instance, since a
> > child instance is also an instance of its parent class ?
> >
> >    
>
> Sure, you should be able to. My guess is some trait isn't defined
> correctly. Are you able to post the code which exhibits the error?
>
> Bryce
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev