segfault on Mac (OSX)

wxPython Users
1

Hi,
I have written some nice wxPython code that displays images (actually using
openGL) and it runs nice and smooth on Windows and Linux (GTK)
But on mac OSX (panther) I irregularity get segfaults. I ran this a couple
time inside gdb and get this trace back:

Program received signal EXC_BAD_ACCESS, Could not access memory.
[Switching to process 732 thread 0x5297]
0xffff8acc in __memcpy ()
(gdb) bt
#0 0xffff8acc in __memcpy ()
#1 0x0207e784 in wxBaseArrayLong::RemoveAt(unsigned long, unsigned
long) ()
#2 0x0204d734 in wxMutexInternal::Unlock() ()
#3 0x0100b618 in wxPyBeginAllowThreads() ()
#4 0x0105e18c in wxIntersectRect(wxRect*, wxRect*) ()
#5 0x95fa94a8 in PyEval_GetFuncDesc ()
#6 0x95fa6c64 in PyEval_EvalCode ()
#7 0x95fa7e30 in PyEval_EvalCodeEx ()
#8 0x95fa97dc in PyEval_GetFuncDesc ()
#9 0x95fa9580 in PyEval_GetFuncDesc ()
#10 0x95fa6c64 in PyEval_EvalCode ()
#11 0x95fa7e30 in PyEval_EvalCodeEx ()
#12 0x95f5f354 in PyFunction_SetClosure ()
#13 0x95f4a8d0 in PyObject_Call ()
#14 0x95f529e8 in PyMethod_New ()
#15 0x95f4a8d0 in PyObject_Call ()
#16 0x95fa91ec in PyEval_CallObjectWithKeywords ()
#17 0x95fd39c0 in _PyObject_GC_Del ()
#18 0x900247e8 in _pthread_body ()

I got this a view times; then I got different trace backs like:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x915621d0 in CopyRgn ()
(gdb) bt
#0 0x915621d0 in CopyRgn ()
#1 0x9156fe8c in GetPortVisibleRegion ()
#2 0x020283dc in wxWindowDC::~wxWindowDC() ()
#3 0x02028964 in wxPaintDC::~wxPaintDC() ()
#4 0x02028c2c in wxMemoryDC::~wxMemoryDC() ()
#5 0x03f21d34 in SurfaceImpl::~SurfaceImpl() ()
#6 0x03f3d22c in Editor::LocationFromPosition(int) ()
#7 0x03f3f514 in Editor::EnsureCaretVisible(bool, bool, bool) ()
#8 0x03f4ec48 in Editor::WndProc(unsigned, unsigned long, long) ()
#9 0x03f58500 in ScintillaBase::WndProc(unsigned, unsigned long, long)
()
#10 0x03f27938 in ScintillaWX::WndProc(unsigned, unsigned long, long) ()
#11 0x03f9c098 in XPMSet::GetWidth() ()
#12 0x95f4a8d0 in PyObject_Call ()
#13 0x95fa9df0 in PyEval_GetFuncDesc ()
#14 0x95fa6d44 in PyEval_EvalCode ()
<snip>

Or this:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0204d6fc in wxMutexInternal::Unlock() ()
(gdb) bt
#0 0x0204d6fc in wxMutexInternal::Unlock() ()
#1 0x0100b618 in wxPyBeginAllowThreads() ()
#2 0x0105a780 in initwindows3c ()
#3 0x95f4a8d0 in PyObject_Call ()
#4 0x95fa9df0 in PyEval_GetFuncDesc ()
<snip>

Please tell me how I can get more helpful info from the debugger.
I have wxVERSION_STRING = '2.4.2.4'.

Thanks,
Sebastian Haase

2

Sebastian Haase wrote:

Hi,
I have written some nice wxPython code that displays images (actually using openGL) and it runs nice and smooth on Windows and Linux (GTK)
But on mac OSX (panther) I irregularity get segfaults. I ran this a couple time inside gdb and get this trace back:

Program received signal EXC_BAD_ACCESS, Could not access memory.
[Switching to process 732 thread 0x5297]
0xffff8acc in __memcpy ()
(gdb) bt
#0 0xffff8acc in __memcpy ()
#1 0x0207e784 in wxBaseArrayLong::RemoveAt(unsigned long, unsigned long) ()
#2 0x0204d734 in wxMutexInternal::Unlock() ()
#3 0x0100b618 in wxPyBeginAllowThreads() ()
#4 0x0105e18c in wxIntersectRect(wxRect*, wxRect*) ()
#5 0x95fa94a8 in PyEval_GetFuncDesc ()
#6 0x95fa6c64 in PyEval_EvalCode ()
#7 0x95fa7e30 in PyEval_EvalCodeEx ()
#8 0x95fa97dc in PyEval_GetFuncDesc ()
#9 0x95fa9580 in PyEval_GetFuncDesc ()
#10 0x95fa6c64 in PyEval_EvalCode ()
#11 0x95fa7e30 in PyEval_EvalCodeEx ()
#12 0x95f5f354 in PyFunction_SetClosure ()
#13 0x95f4a8d0 in PyObject_Call ()
#14 0x95f529e8 in PyMethod_New ()
#15 0x95f4a8d0 in PyObject_Call ()
#16 0x95fa91ec in PyEval_CallObjectWithKeywords ()
#17 0x95fd39c0 in _PyObject_GC_Del ()
#18 0x900247e8 in _pthread_body ()

Don't call wxIntersectRect from an alternate thread. It uses regions to find the intersection and regions use platform APIs to do their thing. (Try not to do any UI stuff at all from the threads.)

Please tell me how I can get more helpful info from the debugger.
I have wxVERSION_STRING = '2.4.2.4'.

Is 2.5.1.5 work better for you?

ยทยทยท

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

3

Mike Fletcher responded to Oliver S:

One feature that I like with pubsub is the concept of 'topics' and,
especially, the hierarchical nature of topics as supported by pubsub.

I can see how such a thing might be interesting, but can you give a
concrete use-case example for it?

This post is a bit old, but here's a delayed response:

I put that feature in there because I'd worked with a couple different P/S
systems, and what I'd found was that there was always the tendency to create
message topics like "something.somethingelse". In other words, developers
were creating a hierarchical topic name space within the string of the topic
itself.

So, it seemed like a good idea to have the P/S system support this
hierarchical space explicitly. I'd used this in a couple of other projects
and so it was natural to put it in with pubsub.

One use case example is logging. Something I commonly do is break the topic
space up into different areas of an application into logical topics, like
"User Action/..." With this hierarchical topic system, it's easy to log or
spy on all the messages of a certain theme, or, all the messages in the
entire system. If new subsections are added, the original logging code
doesn't have to change - it works because it's still semantically meaningful.

It looks like the pubsub issues boil down to:

1) References being held on to.
2) No support for multi-threaded context.
3) No support for callable objects.

I think it'd be cool to fix/replace pubsub to remedy these. One issue,
though, is the reason for pubsub's existence: to support evtmgr.py.

I wrote both at the same time, and realized that the P/S feature could be
written as a totally seperate module which evtmgr would use through a public
API. Seemed like good design, so that's what I did. So, evtmgr needs to be
tested to make sure it works with a new pubsub implementation. To me, that's
the only caveat.

Robb