Hi Stefan, no segfault with gcc2.95.2-built python2.4, see below...still testing. Stefan Behnel <behnel_ml@gkec.informatik.tu-darmstadt.de> schrieb am 17.11.2006 20:06:20:
Hi Holger,
Holger Joukl wrote:
I run into segfaults using a python2.3, gcc 2.95.2 - build (yes I know, mighty old compiler :-):
and difficult to track down problems. Impossible to say if it's because of a specific system environment (who compiled your pthreads, for example? where did your Python binary come from?) or because of the compiler itself, specific compiler options...
Have you tried it with 'safe' options like "-O -m386" and the like? (or
same for Solaris respectively).
Tests work fine with everything gcc3.4.4-built, using python2.4 (same
We compile Python from source, pthreads comes with Solaris afaik. So in theory I have control over the usage of compiler options. I tried some more combinations and do not run into the segfault with a gcc2.95.2-built python2.4.3 So my current best guess would be it is some python2.3-related problem. I _do_ run into the segfault in every combination where I used python2.3 built with gcc2.95.2. I haven't tried building python2.3 with gcc3.4.4 so maybe I will do this if I find time. the lib
versions)
Did you use the same compiler for the libs?
Yes, gcc 3.4.4 for python interpreter, libxml2, libxslt, lxml.
Both segfaults seem to arise when an error is raised internally (though it is unclear why the first is an error - it does not raise an exception when run under python2.4/gcc3.4.4).
But the stack trace tells me that you got a warning from libxml2 that went up into the Python environment: [...] Looks pretty similar to me, both segfault in pthreads mutex calls. Maybe it's not a compiler issue but an issue with Python 2.3 on Solaris - or a mixture of many causes...
Both work fine with python2.4, compiled with gcc 3.4.4: [...]
Uhm, on the same machine? What do you need the gcc 2.95 for, then?
Yes, on the same sparc solaris box. The reason for sticking to gcc 2.95.2 is an old _heavily_ modified boost.python we used to auto-wrap (with openc++) the TIB/Rv-API. Due to different partial template specialization with newer compilers this mechanism cannot be easily changed, if at all. A main reason why we want to get rid of this, migrating either to a newer boost version or another wrapping tool. But we have successfully tried running the old rv module with the gcc3.4.4-built python2.4 so we are not really stuck here.
Personally, I feel no big incentive in supporting a compiler as old as 2.95. GCC is at version 4 by now and if we run fine with 3.4, that's all I'd ask for.
Stefan
For plain C programs I think gcc 2.95.2 should still work. Holger Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Kopieren sowie die unbefugte Übermittlung sind nicht gestattet. Die Sicherheit von Übermittlungen per E-Mail kann nicht garantiert werden. Falls Sie eine Bestätigung wünschen, fordern Sie bitte den Inhalt der E-Mail als Hardcopy an. The contents of this e-mail are confidential. If you are not the named addressee or if this transmission has been addressed to you in error, please notify the sender immediately and then delete this e-mail. Any unauthorized copying and transmission is forbidden. E-Mail transmission cannot be guaranteed to be secure. If verification is required, please request a hard copy version.