Hi Marco,
On my machine, the _Visualization.pyd file (Windows) depends on TKBrep.dll,
TKernel.dll, TKMath.dll, TKNIS.dll, TKPrim.dll, TKService.dll, TKTopAlgo.dll,
TKV2d.dll and TKV3d.dll. I think your libTKernel.so bug comes from a bad
call/definition of _Visualization.
Do this bug occus only from Visualization (i.e, can you create for instance a
simple gp_Pnt from a python console)? It reminds me I really have to start to
build a set of unit tests.
You can try to creat e a graphic driver directly from python:
> from OCC.Graphic3d import *
> gd = Graphic3d_GraphicDevice(':0.0')
> print gd
Thomas
>Hi Arthur,
>
>Thanks for the tip. Stupid enough I did not check the logs. Much to my
>surprise, the problem does not seem to be in the visualization part:
>
>ipython[23316]: segfault at fefd0008 ip 00007f90637a1bdf sp
>00007fff752d7740 error 4 in libTKernel.so.0.0.0[7f9063673000+23a000]
>
>As you can see, the segfault seems to come from libTKernel.so.
>
>Hmmm.....probably it is time to launch a debugger.
>
>Marco
>
>On Sun, Mar 22, 2009 at 1:31 PM, Arthur Magill <arthur.mag...@epfl.ch> wrote:
>> Hey Marco,
>>
>> Have you checked /var/log/messages, or dmesg, to see if that gives you any
>> clues? If you're having trouble with your graphics driver, there should be
>> something in the logs.
>>
>> Arthur
>>
>> M. Nawijn wrote:
>>>
>>> Hi Thomas,
>>>
>>> Unfortunately, the visualization stuff segfaults directly on my
>>> system. I will try to take a look into the SWIG wrappers/interface
>>> files to see if I can find something. I think I need to check several
>>> options:
>>> - I use accelerated NVIDIA drivers (64bit) maybe I should try to
>>> go back to plain drivers and see what happens
>>> - Recompile in debug mode and go through the graphic device
>>> generation process (I tried to create a graphic device
>>> "Graphic3d_GraphicDevice" by hand, but cannot figure out the correct
>>> constructor call. The obvious ones fail.)
>>> - Check the Xw_* code
>>>
>>> I keep you posted!
>>>
>>> Marco
>>>
>>> On Sat, Mar 21, 2009 at 5:42 AM, Thomas Paviot <thomas.pav...@free.fr>
>>> wrote:
>>>>
>>>> M. Nawijn a écrit :
>>>>>
>>>>> On Fri, Mar 20, 2009 at 4:18 PM, <thomas.pav...@free.fr> wrote:
>>>>>
>>>>>>>>> Objet: Re: [Pythonocc-users] Scons script update
>>>>>>>>>
>>>>>>>>> Hi Guys,
>>>>>>>>>
>>>>>>>>> It is me again. With the new added compile options, the SWIG
>>>>>>>>> generation and compilation succeeded
>>>>>>>>> without any problem.
>>>>>>>>>
>>>>>>>>> Than it started to get exciting. Would the bottle fail me again?
>>>>>>>>> NO.... It worked!!!
>>>>>>>>>
>>>>>>>> What an excellent news!
>>>>>>>>
>>>>>>>
>>>>>>>> This effectively means that the -D_OCC64 and possible -m64
>>>>>>>> compilation
>>>>>>>> options should be enabled
>>>>>>>> on 64 bit platforms.
>>>>>>>>
>>>>>>> I'll add this to the SConstruct file. I have to detect, from Python,
>>>>>>> that your processor is 64 bits.
>>>>>>>
>>>>>>>
>>>>>>>> One final problem to solve. It seems like the viewer part is not
>>>>>>>> working correctly for my system. If I try to execute
>>>>>>>> the wxDisplay script on Windows it provides me with a viewer showing
>>>>>>>> a
>>>>>>>> brick/box. On my Linux machine,
>>>>>>>> a short flash is seen, than the script terminates.
>>>>>>>>
>>>>>>>> The only output I get is:
>>>>>>>>
>>>>>>>>
>>>>>>>>>> python wxDisplay.py
>>>>>>>>>>
>>>>>>>> Display3d class initialization starting ...
>>>>>>>>
>>>>>>>> Any suggestions?
>>>>>>>>
>>>>>>> No more error message? It certainly means that it does not come from
>>>>>>> OCC. What wxPython version do you use?
>>>>>>>
>>>>>> Name : wxPython
>>>>>> Arch : x86_64
>>>>>> Version : 2.8.9.1
>>>>>> Release : 1.fc9
>>>>>>
>>>>> I think I got it: check the __init__.py script in your /site-packages
>>>>> directory.
>>>>>
>>>>> You may have a line like:
>>>>> export['CSF_GraphicShr']='/usr/local/lib/libTKOpenGL.so'
>>>>> This overwrites the one you defined.
>>>>>
>>>>> Just comment out this line ansd everything should be ok.
>>>>>
>>>> Hmmm.... this is not the case. The variable is set to the correct
>>>> value. I checked this by printing the value prior to
>>>> driver initialisation. I tracked the error down to the following call
>>>> in OCCViewer.BaseDriver
>>>>
>>>> self.Init(self._window_handle)
>>>>
>>>> This one fails. I checked if I have a correct window handle and it
>>>> looks reasonable.This call is directly forward to the C++ side, so I
>>>> probably have to dig in this.
>>>>
>>>> Another option could be to first try it with an ordinary X Window
>>>> instead of going through the wx stuff.
>>>>
>>>> Bye,
>>>>
>>>> Marco
>>>>
>>>>
>>>>
>>> Hi Marco,
>>>
>>> In order to check whether it comes from OCC or wxPython, here is the
>>> following test case (it's not necessary to run wxDisplay.py):
>>>
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>
>>>>>> from OCC.Visualization import *
>>>>>> d = Display3d()
>>>>>> d.Init(0) #pass a 'fake' widnow handler
>>>
>>> Display3d class initialization starting ...
>>> Graphic device created.
>>> *Xw_Error_4/1*code 3/'BadWindow (invalid Window parameter)'
>>> from Xw_error_handler routine
>>> *Xw_Error_3/2*Bad Window 0 Attributes from Xw_get_window_position routine
>>> Xw_Window created.
>>> Viewer created.
>>> *Xw_Error_3/1*Bad EXT_WINDOW Address 0 from Xw_get_window_size routine
>>> Segmentation fault
>>>
>>> I ran this on Ubuntu. If the line "Graphic Device Created" is not
>>> displayed,
>>> then it may come from:
>>> - an OpenGL issue,
>>> - the CSF_GraphicShr env var is not properly set
>>>
>>> Cheers,
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Pythonocc-users mailing list
>> Pythonocc-users@gna.org
>> https://mail.gna.org/listinfo/pythonocc-users
>
>
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
