Illegal storage access...

[jriegel]

You right, its the same problems with the most python bindings. We will have the same problems with PythonOCC and nothing to say PyQT with SIP....
I constantly struggle to incorporate this bindings in the FreeCAD build process.

I was not aware that ATI got so much difficulties on Linux! Hopefully that get solved, we need a stable performant 3D subsystem to run FreeCAD.

[yorik]

Okay, I managed to go a bit further.
I managed to build a working pivy package from the debian pivy package project that Teemu made some time ago (see http://sourceforge.net/forum/message.php?msg_id=5804069 ). The source package for debian is here: http://git.debian.org/?p=collab-maint/pivy.git

That package compiled and installed fine (Just had to change the libsoqt4-dev dependency from 1.4.2a to 1.4).
If I run it from python (for example I create a SoGuiExaminerViewer with a cone inside, the "classical" pivy example), it works fine.
In a python console too, just doing this:

Code: Select all

from pivy import coin
scene=coin.SoSeparator()
cube=coin.SoCube()
scene.addChild(cube)

works, returns no error.

In FreeCAD, however, doing this:

Code: Select all

from pivy import coin
scene=coin.SoSeparator()
cube=coin.SoCube()
scene.addChild(cube)
sg=Gui.ActiveDocument.ActiveView.getSceneGraph()
sg.addChild(scene)

returns this error:

Traceback (most recent call last):
File "<input>", line 1, in <module>
File "/var/lib/python-support/python2.5/pivy/coin.py", line 41175, in addChild
return _coin.SoGroup_addChild(*args)
TypeError: in method 'SoGroup_addChild', argument 1 of type 'SoGroup *'

That's already a progress... What you think of this error? Any idea?

[flolli]

About Flolli's errors I really think that there is a bug in OCC package for Suse 64-bit.

Werner

It's me again. Yes, the error was as you mentioned only in the 64-bit version.
I installed openSuSe again on that machine, but this time the 32-bit version.
And see there, no more problems, everything works just fine!!

Also, the segfaults disappeared as you mentioned! Great news!!
I will continue to work with FreeCAD and install latest versions. As soon as i encounter problems, i will give you guys feedback!!

Mabye you could also help me:
I am trying to exchange information between the CAD-system and some app outside.
Until now i am trying to work with sockets inside FreeCAD to receive messages from other computers.
Any suggestions about that?

Greetings,
Florian@Stuttgart

[wmayer]

Hi everybody,

@Yorik:

Sorry, I have no idea why pivy fails in this case. Today I've setup Debian testing 32-bit in a virtual machine and could reproduce all the problems you've reported:

* FreeCAD: SoType.cpp:661: SbName SoType::getName() const: Assertion `!this->isBad()' failed.
I assume this is a bug in the new Coin because it occurs when calling SoQt::done() which should free some resources when shutting down the application. Since this call is actually not really needed because the OS frees the resources anyway I decided to comment out the concerning code.

* Segmentation fault:
As I've already assumed this is still a problem with OpenCV. This crash only happens if the Image module which links to OpenCV was loaded. There is nothing we can do unless waiting for a fixed version. On Ubuntu Intrepid we had this problem too but Ubuntu Jaunty has this fixed already.

* pivy
When trying to compile pivy with Coin 3.0 I get the same error messages you've reported. I have to check the unofficial debain package you mentioned and will report my experiences shortly...


@Flolli:
Nice to hear that the 32-bit version solves your problems. But just one question: is there an official Suse package for OpenCascade out there or did you compile the sources on your own? If it's an official package then I think we should locate the problem a bit more and should issue a bug report.

When using the Qt library then working with TCP sockets is quite straight forward. For simple solutions I think this is sufficient. However, if you need something more powerful then you should have a look on a Middleware like CORBA. But in this field I don't have any experiences so far...

Cheers,
Werner

[yorik]

Thanks for working on this, Werner. I'll also try to dig further, see if I can see differences between the two pivys, etc.

[wmayer]

Good news! I got pivy working under Debian testing.

The problem was that under Debian testing SWIG is in version 1.3.36 available but in FreeCAD we have supported only SWIG-generated Python modules for 1.3.25, 1.3.33 and 1.3.38. Adding the new runtime header file (to access internal objects from within C++ code) solved the problem.

[yorik]

Fantastic! Even more beautiful: the other error, the segfault error, disappeared too !!!!
I now have a perfect, totally functionning FreeCAD!
Well done once again Werner! And thanks!
That swig thing is complicated... everytime they change versions the stuff compiled with it not valid anymore! not very easy

[wmayer]

Yes the swig stuff could become to a problem sooner or later. At the moment I have implemented small wrapper functions which hide the intricacies of the swig stuff. I have such wrapper functions for each swig version. When querying the internals of the loaded (swig) python module I always start with the wrapper for the lowest version. If it fails then I try the next and so forth.

But what is when it seems to succeed but in fact it doesn't? Because this is what has happened in your case. OK in your case the wrapper for 1.3.38 failed while 1.3.36 was required. But what if this appears sometime the other way round?

This is something we must always be aware of...

[yorik]

Actually I still cannot compile Pivy together with FreeCAD (I used one I compiled myself from the Teemu's debian package above)... It seems that there is a difference. If I downloade the latest svn version of pivy from the official site, I can compile, but it doesn't work. What a bore!
I just downloaded and compiled pythonOCC too (btw, it's getting really advanced, it begins to be very interesting), and it looks like it suffers of the very same problems as pivy. All swig's fault!
In fact, the files in freecad/pivy source and in Teemu's sources seem different. I'll investigate more.
Cheers
Yorik

[wmayer]

Now we fell into the swig version trap. A few days ago I tested the prebuilt pythonocc libs for Windows. Apparently they were generated with swig 1.3.38. After I have added the code to support pivy under Debian testing which uses swig 1.3.36 pythonocc doesn't work anymore. This is because when I try to query some internals of the pythonocc with the access methods generated for 1.3.36 it apparently works but lateron the returned objects are unusable.

So, the dilemma is that when we keep the code for 1.3.36 pivy works but not pythonocc and if we remove it pythonocc works but no longer pivy. The only way out of this dilemma is to make sure that all swig-generated libraries are built with exactly the same swig version number.

On Linux based systems this shouldn't be too complicated. We simply have to embed the recognition of swig in the build procedure of FreeCAD and generate the swig interface file (containing the needed access methods) at build time. The pivy and pythonocc modules must be built separately for every Linux distribution anyway. I would then remove the pivy sources from the FreeCAD build procedure because the sources compile only with certain swig & Coin3d versions anayway. Instead we should then use Teemu's unofficial pivy package which I hope works with all swig & Coin3d combinations.

For Windows we must find an agreement which swig version we want to use and then build pivy and pythonocc with exactly this version and pre-generate the above swig interface file which is a simple header file.

BTW, on which platform did you build the pythonocc sources? On Linux (Debian/Ubuntu) or on Windows? Did it work out of the box?