On Mon, Mar 23, 2009 at 6:49 AM, <thomas.pav...@free.fr> wrote:
> 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.
As far as I can tell, it only occurs for the Visualization part. The
pythonOCC bottle example runs without a problem. In the mean time I
recompiled OCC from scratch, since for some reason I did not have
DRAWEXE. The compilation process ran without problems and at least
DRAWEXE can generate graphics windows. This might indicate that the
problem is not in the NVIDIA driver.
Can you explain why it is a bad call/definition and why this bites only me?
Bye and thanks again,
Marco
P.S. Once I have everything up and running I will help creating unittests.
> You can tryi 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
