"segmentation fault" from Sax2 with wxPython2.8

Previously I wrote a GUI with Python 2.4.3, wxPython 2.4.x, under
linux. Now I am porting it with python 2.6.6, and wxPython 2.8 (I
compiled the code from scratch). The majority of the GUI still works.
But there are some problems with Sax2. The following is some major
lines of code.

from xml.dom.ext.reader import Sax2

reader = Sax2.Reader()
file = open(FILENAME)
file_string=file.read()
doc = reader.fromString(file_string) // crashes here with
"segmentation fault" error.

However, If I do not use wxPython, just under the python, it is fine.

what is the problem?

Previously I wrote a GUI with Python 2.4.3, wxPython 2.4.x, under
linux. Now I am porting it with python 2.6.6, and wxPython 2.8 (I
compiled the code from scratch). The majority of the GUI still works.
But there are some problems with Sax2. The following is some major
lines of code.

from xml.dom.ext.reader import Sax2

reader = Sax2.Reader()
file = open(FILENAME)

is this save? "file" is a Python built-in which you overwrite and "open" returns a "file" type.

would be better to call it e.g. "saxFile" or "myFile" ....

file_string=file.read()
doc = reader.fromString(file_string) // crashes here with
"segmentation fault" error.

However, If I do not use wxPython, just under the python, it is fine.

None of the above shows wx code, can you re-produce this in a small sample? If you do "import wx" before the above code does it already happen or is more needed?

Werner

···

On 01/02/2012 16:27, pploo wrote:

Hi, Werner, thanks for your post. But, I am sorry it does not really
help or relevant.

It seems there are some problems between wxPython and the xml parser.
Unfortunately, I just have no clue where this "segmentaton fault"
comes from, what it is exactly, and how to overcome it.

···

On Feb 1, 4:56 pm, werner <wbru...@free.fr> wrote:

On 01/02/2012 16:27, pploo wrote:> Previously I wrote a GUI with Python 2.4.3, wxPython 2.4.x, under
> linux. Now I am porting it with python 2.6.6, and wxPython 2.8 (I
> compiled the code from scratch). The majority of the GUI still works.
> But there are some problems with Sax2. The following is some major
> lines of code.

> from xml.dom.ext.reader import Sax2

> reader = Sax2.Reader()
> file = open(FILENAME)

is this save? "file" is a Python built-in which you overwrite and
"open" returns a "file" type.

would be better to call it e.g. "saxFile" or "myFile" ....> file_string=file.read()
> doc = reader.fromString(file_string) // crashes here with
> "segmentation fault" error.

> However, If I do not use wxPython, just under the python, it is fine.

None of the above shows wx code, can you re-produce this in a small
sample? If you do "import wx" before the above code does it already
happen or is more needed?

Werner

Previously I wrote a GUI with Python 2.4.3, wxPython 2.4.x, under
linux. Now I am porting it with python 2.6.6, and wxPython 2.8 (I
compiled the code from scratch). The majority of the GUI still works.
But there are some problems with Sax2. The following is some major
lines of code.

from xml.dom.ext.reader import Sax2

reader = Sax2.Reader()
file = open(FILENAME)

is this save? "file" is a Python built-in which you overwrite and "open"
returns a "file" type.

It just overwrites the "file" name in the local namespace. Not a good idea but it shouldn't cause a crashing problem.

would be better to call it e.g. "saxFile" or "myFile" ....

file_string=file.read()
doc = reader.fromString(file_string) // crashes here with
"segmentation fault" error.

However, If I do not use wxPython, just under the python, it is fine.

None of the above shows wx code, can you re-produce this in a small
sample? If you do "import wx" before the above code does it already
happen or is more needed?

IIRC there was an issue like this long ago that had something to do with runtime conflicts or version mismatches between the expat library used by wxWidgets and the expat used by the xml modules. In that case import order made a difference, and I think the problem was resolved by minor changes in the builds (like having Python static link expat instead of dynamic linking it or something.) Did you build your Python yourself?

···

On 2/1/12 7:56 AM, werner wrote:

On 01/02/2012 16:27, pploo wrote:

--
Robin Dunn
Software Craftsman

Hi,

Got curious about this xml parser as I use Amara for XML stuff.

Hi, Werner, thanks for your post. But, I am sorry it does not really
help or relevant.

It seems there are some problems between wxPython and the xml parser.
Unfortunately, I just have no clue where this "segmentaton fault"
comes from, what it is exactly, and how to overcome it.

On 01/02/2012 16:27, pploo wrote:> Previously I wrote a GUI with Python 2.4.3, wxPython 2.4.x, under

linux. Now I am porting it with python 2.6.6, and wxPython 2.8 (I
compiled the code from scratch). The majority of the GUI still works.
But there are some problems with Sax2. The following is some major
lines of code.
from xml.dom.ext.reader import Sax2

This line gives me an import error on Python 2.7.2 and looking at the doc for Python 2.6.7 it looks like SAX2 is implemented in xml.sax.

...

None of the above shows wx code, can you re-produce this in a small
sample? If you do "import wx" before the above code does it already
happen or is more needed?

So, I think my last para of the previous post, show above might be relevant :slight_smile:

Just my 0.02�
Werner

···

On 01/02/2012 18:15, pploo wrote:

On Feb 1, 4:56 pm, werner<wbru...@free.fr> wrote:

Hi, Robin and Werner,

the python is available from the Linux distribution I have, and I did
not compile it.
could you please elabrate more about this point, i.e., what is
conflicting with what, and why it can conflict.
I am sorry, even though I read some articles about how python import
mechanism work, I still struggle to understand why such version
dismatch or lib conflict exist.

I made a short script and hope this could reproduce the problem.

@Robin, how to change the order of the import? it seems not work.

from xml.dom.ext.reader import Sax2
import wx

def read_by_xml_parser ():
    f_string="<wxpython_xml>problem</wxpython_xml>"
    reader = Sax2.Reader()
    try:
        print "test1_xml"
        doc = reader.fromString(f_string)
    except IOError, e:
        print e

class ErrorApp(wx.App):
    def OnInit(self):
        print "test0_xml"
        frame = wx.Frame(None, -1, 'error_test')
        frame.Show(True)
        read_by_xml_parser()
        return True

app = ErrorApp(0)
app.MainLoop()

···

On Feb 1, 7:28 pm, Robin Dunn <ro...@alldunn.com> wrote:

On 2/1/12 7:56 AM, werner wrote:

> On 01/02/2012 16:27, pploo wrote:
>> Previously I wrote a GUI with Python 2.4.3, wxPython 2.4.x, under
>> linux. Now I am porting it with python 2.6.6, and wxPython 2.8 (I
>> compiled the code from scratch). The majority of the GUI still works.
>> But there are some problems with Sax2. The following is some major
>> lines of code.

>> from xml.dom.ext.reader import Sax2

>> reader = Sax2.Reader()
>> file = open(FILENAME)
> is this save? "file" is a Python built-in which you overwrite and "open"
> returns a "file" type.

It just overwrites the "file" name in the local namespace. Not a good
idea but it shouldn't cause a crashing problem.

> would be better to call it e.g. "saxFile" or "myFile" ....
>> file_string=file.read()
>> doc = reader.fromString(file_string) // crashes here with
>> "segmentation fault" error.

>> However, If I do not use wxPython, just under the python, it is fine.
> None of the above shows wx code, can you re-produce this in a small
> sample? If you do "import wx" before the above code does it already
> happen or is more needed?

IIRC there was an issue like this long ago that had something to do with
runtime conflicts or version mismatches between the expat library used
by wxWidgets and the expat used by the xml modules. In that case import
order made a difference, and I think the problem was resolved by minor
changes in the builds (like having Python static link expat instead of
dynamic linking it or something.) Did you build your Python yourself?

--
Robin Dunn
Software Craftsmanhttp://wxPython.org

from xml.dom.ext.reader import Sax2
reader = Sax2.Reader()

import wx

def read_by_xml_parser ():
    f_string="<wxpython_xml>problem</wxpython_xml>"
    try:
        print "test1_xml"
        doc = reader.fromString(f_string)
    except IOError, e:
        print e

class ErrorApp(wx.App):
    def OnInit(self):
        print "test0_xml"
        read_by_xml_parser()
        frame = wx.Frame(None, -1, 'error_test')
        frame.Show(True)
        return True

app = ErrorApp(0)
app.MainLoop()

If I do something as above, i.e., call the "reader = Sax2.Reader()"
before the entry function "wx.App" starts, it is fine. my dear
friends, what is wrong here?

···

On Feb 6, 12:03 pm, pploo <beilus...@gmail.com> wrote:

Hi, Robin and Werner,

the python is available from the Linux distribution I have, and I did
not compile it.
could you please elabrate more about this point, i.e., what is
conflicting with what, and why it can conflict.
I am sorry, even though I read some articles about how python import
mechanism work, I still struggle to understand why such version
dismatch or lib conflict exist.

I made a short script and hope this could reproduce the problem.

@Robin, how to change the order of the import? it seems not work.

from xml.dom.ext.reader import Sax2
import wx

def read_by_xml_parser ():
f_string="<wxpython_xml>problem</wxpython_xml>"
reader = Sax2.Reader()
try:
print "test1_xml"
doc = reader.fromString(f_string)
except IOError, e:
print e

class ErrorApp(wx.App):
def OnInit(self):
print "test0_xml"
frame = wx.Frame(None, -1, 'error_test')
frame.Show(True)
read_by_xml_parser()
return True

app = ErrorApp(0)
app.MainLoop()

On Feb 1, 7:28 pm, Robin Dunn <ro...@alldunn.com> wrote:

> On 2/1/12 7:56 AM, werner wrote:

> > On 01/02/2012 16:27, pploo wrote:
> >> Previously I wrote a GUI with Python 2.4.3, wxPython 2.4.x, under
> >> linux. Now I am porting it with python 2.6.6, and wxPython 2.8 (I
> >> compiled the code from scratch). The majority of the GUI still works.
> >> But there are some problems with Sax2. The following is some major
> >> lines of code.

> >> from xml.dom.ext.reader import Sax2

> >> reader = Sax2.Reader()
> >> file = open(FILENAME)
> > is this save? "file" is a Python built-in which you overwrite and "open"
> > returns a "file" type.

> It just overwrites the "file" name in the local namespace. Not a good
> idea but it shouldn't cause a crashing problem.

> > would be better to call it e.g. "saxFile" or "myFile" ....
> >> file_string=file.read()
> >> doc = reader.fromString(file_string) // crashes here with
> >> "segmentation fault" error.

> >> However, If I do not use wxPython, just under the python, it is fine.
> > None of the above shows wx code, can you re-produce this in a small
> > sample? If you do "import wx" before the above code does it already
> > happen or is more needed?

> IIRC there was an issue like this long ago that had something to do with
> runtime conflicts or version mismatches between the expat library used
> by wxWidgets and the expat used by the xml modules. In that case import
> order made a difference, and I think the problem was resolved by minor
> changes in the builds (like having Python static link expat instead of
> dynamic linking it or something.) Did you build your Python yourself?

> --
> Robin Dunn
> Software Craftsmanhttp://wxPython.org

All I can comment on for sure is what was going on the last time I experienced this myself, but it sounds like your case is the same or similar. In the prior case the cause of the problem was the expat library, which is commonly used for parsing XML. wxWidgets used one version of it and the Python xml module used another version. I'm not sure if they were both dynamically linked or if one or the other was static linked with expat, but basically when the two modules were loaded the one that used the newer expat was trying to call functions that didn't exist in the older expat which was loaded in memory, so it would crash. By reversing the order then the newer expat was loaded into memory first and the module expecting to use the older expat was okay because it was backwards compatible.

···

On 2/6/12 3:03 AM, pploo wrote:

Hi, Robin and Werner,

the python is available from the Linux distribution I have, and I did
not compile it.
could you please elabrate more about this point, i.e., what is
conflicting with what, and why it can conflict.
I am sorry, even though I read some articles about how python import
mechanism work, I still struggle to understand why such version
dismatch or lib conflict exist.

--
Robin Dunn
Software Craftsman

Maybe the OP should try lxml instead. I think it uses ElementTree, the latter of which is included with Python, as I recall. I’ve used it in wxPython with no issues.

···

Mike Driscoll
www.mousevspython.com

I still don't get how the OP's sample script should work, he wants to move to Python 2.6 and with 2.6 or 2.7 I get an import error on the first line of the script.

from xml.dom.ext.reader import Sax2

Is it just me? And as per Python doc the SAX2 stuff is in xml.sax, maybe that implementation does not have that issue.

Werner

···

On 07/02/2012 22:32, Mike Driscoll wrote:

Maybe the OP should try lxml instead. I think it uses ElementTree, the latter of which is included with Python, as I recall. I've used it in wxPython with no issues.

Good catch. I think the PyXml package installs itself into the xml.dom.ext package, or at least it used to. They haven't had a release since 2004 however, there are several newer and better packages that could (and should) be used instead.

···

On 2/8/12 12:42 AM, werner wrote:

On 07/02/2012 22:32, Mike Driscoll wrote:

Maybe the OP should try lxml instead. I think it uses ElementTree, the
latter of which is included with Python, as I recall. I've used it in
wxPython with no issues.

I still don't get how the OP's sample script should work, he wants to
move to Python 2.6 and with 2.6 or 2.7 I get an import error on the
first line of the script.

from xml.dom.ext.reader import Sax2

Is it just me? And as per Python doc the SAX2 stuff is in xml.sax, maybe
that implementation does not have that issue.

--
Robin Dunn
Software Craftsman