I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m

cc -version
MIPSpro Compilers: Version 7.3.1.3m

- make tests passes test_pyexpat without error
- running this code leads to a core dump

-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)

<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)

- running this code from an interactive session leads
not to a coredump

I need some assistance howto provide further debug
information.

--maik./

Logged In: YES 
user_id=471223

I also got a core dump importing pyexpat on Solaris (SPARC)
and somebody else reported it on a *BSD system.

It appears to be a problem with older versions of expat not
being tested for.  I used gdb to trace it down to line 1972
in pyexpat.c where it attempts to define the first constant
from 1.95.8.  I had expat 1.95.7.  After upgrading to 1.95.8
it worked fine, as did the *BSD system. 

I think Python needs to check the expat version, as it does
elsewhere in the file, before defining those constants. 

I am still puzzelled over how it managed to compile
pyexpat.c in the first place...

Logged In: YES 
user_id=6656

Uh, Python includes its own copy of expat, and I really
thought we were supposed to prefer our own version over
anything found on the system...

Logged In: YES 
user_id=471223

Maybe it compiled against its own copy of expat, but pulled
in the system's copy when run?  

Logged In: YES 
user_id=471223

I've looked at the program that was dumping core and the
sequence is this:

1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which
in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already
linked in XML_ErrorString from /usr/local/lib/libexpat.so it
calls that version, not the one in pyexpat.so.  
5) pyexpat looks up an error defined by the later version of
expat it is expecting and gets a NULL pointer from the
earlier version it has.  It attempts to use it without
checking (strlen) and dumps core.

Logged In: YES 
user_id=6656

1) Good sleuthing.
2) Argh!
3) What happens if you import pyexpat before pygtk?

Logged In: YES 
user_id=471223

pyexpat initializes using its internal copy of expat. 
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.

I suspect that this will be a problem if the system version
of expat is newer than Python's.

Logged In: YES 
user_id=28380

I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.

It's not actually necessary to check the expat version; just see if XML_ErrorString actually returns anything.

Here's the patch I use for this problem:

--- python/Modules/pyexpat.c        2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c  2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
     }
 #endif

-#define MYCONST(name) \
-    PyModule_AddStringConstant(errors_module, #name, \
-                               (char*)XML_ErrorString(name))
+#define MYCONST(name)                           \
+    { \
+        char *_v = (char*)XML_ErrorString(name); \
+        if (_v) \
+            PyModule_AddStringConstant(errors_module, #name, _v); \
+    }

     MYCONST(XML_ERROR_NO_MEMORY);
     MYCONST(XML_ERROR_SYNTAX);

Logged In: YES 
user_id=28380

By the way, this is not an SGI-specific bug. This will bite any Unix system with a modern sysv-style dynamic linker. The priority of this bug should be higher, IMO.

Logged In: YES 
user_id=6656

It's a nasty one, I'll give you that.

Fred, what do you think of bos's patch?  It solves the immediate issue, 
but I'm not sure it's a complete fix.

It seems to me that it would be better to resolve the expat symbols at 
builf time, but I don't know how to arrange for that.

Logged In: YES 
user_id=28380

With the GNU linker, you can pass in -Bstatic to force it to resolve the symbols in the local shared library, instead of globally. This also works on Irix. I don't know about other Unixes.

Logged In: YES 
user_id=2369

I ran into this problem as well on a debian GNU/Linux system
on x86 hardware.  It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.

bos' patch at least solves the immediate problem of the
segmentation fault.  It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.

Logged In: YES 
user_id=1315245

FWIW, this same problem crops up when using Python & VTK
together (which also ships with its own version of expat). 
bos's workaround will make things work, though.

Logged In: YES 
user_id=33168

The problem seems to be related (same?) as bug #1295808. 
Does the patch there fix these problems?

Logged In: YES 
user_id=21627

I think the problem will occur whenever somebody loads
libexpat.so with dlopen and RTLD_GLOBAL. IMO, this should be
avoided. I can't see in which of these different reports
this really is the case, but in those cases, this much looks
like a third-party bug.

If you import pyexpat first, it looks fine, since it will
resolve the symbols against its own copy, without exporting
them. Then, the later usage of libexpat cannot mistakenly go
into pyexpat because Python loaded this with RTLD_LOCAL.
However, it still may crash later when symbols are resolved
lazily, as more expat symbols might be needed when using
pyexpat, so different symbols might go to different libraries.

Linking pyexpat with -Bsymbolic (where available) should
also solve the problem.

Logged In: YES 
user_id=849994

This should be addressed by patch #1295808.

Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).