Debugging wxPython crash

wxPython Users
1

I’ve gotten wxPython 4 running on my Mac, but after running a bit it always crashes with output like “Segmentation fallout: 11”. I’ve stepped through my code, and it doesn’t happen at a particular line; it feels more or less random.

Looking in Console.app, I found the crash logs, but I can’t understand them well enough to figure out the problem. Here’s one such log: https://pastebin.com/39GEbdmH

Can anyone shed some light on this?

– Ed Leafe

P.S. - I sent this exact message via email several hours ago without it showing up in the group, so I’m trying to post directly.

2

Can you create a small standalone sample that shows the problem? The crash happened in the C++ wxMenuBase::UpdateUI method, so it’s likely that it’s related to the menus or associated windows in some way. Perhaps something like trying to use pushed event handlers for items that have already been destroyed, or trying to recursively invoke UpdateUI for submenus that are in the process of being deleted, etc. HOpefully you can narrow things down from those hints.

···

On Thursday, January 24, 2019 at 11:30:25 AM UTC-8, Ed Leafe wrote:

I’ve gotten wxPython 4 running on my Mac, but after running a bit it always crashes with output like “Segmentation fallout: 11”. I’ve stepped through my code, and it doesn’t happen at a particular line; it feels more or less random.

Looking in Console.app, I found the crash logs, but I can’t understand them well enough to figure out the problem. Here’s one such log: https://pastebin.com/39GEbdmH

Can anyone shed some light on this?

–

Robin

3

I’ve gotten wxPython 4 running on my Mac, but after running a bit it always crashes with output like “Segmentation fallout: 11”. I’ve stepped through my code, and it doesn’t happen at a particular line; it feels more or less random.

Looking in Console.app, I found the crash logs, but I can’t understand them well enough to figure out the problem. Here’s one such log: https://pastebin.com/39GEbdmH

Can anyone shed some light on this?

Can you create a small standalone sample that shows the problem? The crash happened in the C++ wxMenuBase::UpdateUI method, so it’s likely that it’s related to the menus or associated windows in some way. Perhaps something like trying to use pushed event handlers for items that have already been destroyed, or trying to recursively invoke UpdateUI for submenus that are in the process of being deleted, etc. HOpefully you can narrow things down from those hints.

–

Robin

I’m one of the authors of Dabo (https://dabodev.com), and after a long hiatus I’m trying to get it running with Python3 and wxPython 4.x. The crash is definitely menu-related, as it happens when I try to click on the View or Help menus. The standard Dabo menubar has the typical “File/Edit/View/Help” menus; File and Edit seem to work fine, but attempting to open up View causes an immediate segfault.

So without installing the experimental Dabo 3 code, it would be hard to post a sample to reproduce. Since Dabo wraps the wx objects, it’s very possible that the change from classic wxPython to Phoenix changed the order of creation/destruction, now that the two-phase construction is a thing of the past. I suppose I’ll have to revisit the entire process of wrapping menu events.

Here is some additional debug information from Console, in case that helps to understand the error more clearly:

error 10:02:00.379605 -0600 cfprefsd rejecting write of key _DKThrottledActivityLast_DKKnowledgeStorageLogging_DKKnowledgeStorageDidInsertEventsNotification:/app/usageActivityDate in { com.apple.contextstored, root, kCFPreferencesAnyHost, no container, managed: 0 } from process 184 because setting preferences outside an application’s container requires user-preference-write or file-write-data sandbox access

error 10:02:00.383774 -0600 contextstored Couldn’t write value for key _DKThrottledActivityLast_DKKnowledgeStorageLogging_DKKnowledgeStorageDidInsertEventsNotification:/app/usageActivityDate in CFPrefsPlistSource<0x7f87c9d06060> (Domain: com.apple.contextstored, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): setting preferences outside an application’s container requires user-preference-write or file-write-data sandbox access

error 10:02:00.386501 -0600 cfprefsd rejecting write of key _DKThrottledActivityLast_DKKnowledgeStorageLogging_DKKnowledgeStorageDidInsertLocalEventsNotification:/app/usageActivityDate in { com.apple.contextstored, root, kCFPreferencesAnyHost, no container, managed: 0 } from process 184 because setting preferences outside an application’s container requires user-preference-write or file-write-data sandbox access

error 10:02:00.387799 -0600 contextstored Couldn’t write value for key _DKThrottledActivityLast_DKKnowledgeStorageLogging_DKKnowledgeStorageDidInsertLocalEventsNotification:/app/usageActivityDate in CFPrefsPlistSource<0x7f87c9d06060> (Domain: com.apple.contextstored, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: Yes): setting preferences outside an application’s container requires user-preference-write or file-write-data sandbox access

error 10:02:00.421395 -0600 sandboxd Sandbox: contextstored(184) deny(1) file-write-data /private/var/root/Library/Preferences/com.apple.contextstored.plist

Violation: deny(1) file-write-data /private/var/root/Library/Preferences/com.apple.contextstored.plist

Process: contextstored [184]

Path: /System/Library/PrivateFrameworks/CoreDuetContext.framework/Versions/A/Resources/contextstored

Load Address: 0x1076b0000

Identifier: contextstored

Version: ??? (???)

Code Type: x86_64 (Native)

Parent Process: launchd [1]

Responsible: /System/Library/PrivateFrameworks/CoreDuetContext.framework/Resources/contextstored [184]

User ID: 0

Date/Time: 2019-01-25 10:02:00.399 CST

OS Version: Mac OS X 10.14.2 (18C54)

Report Version: 8

– Ed Leafe

···

On Friday, January 25, 2019 at 10:04:07 AM UTC-6, Robin Dunn wrote:

On Thursday, January 24, 2019 at 11:30:25 AM UTC-8, Ed Leafe wrote:

4

I have seen lots of seg faults from wxpython on the Mac over the years when same code runs fine with other OSes. The cause is usually a callback routine referencing a widget that has been deleted. Debugging can be tough since GUI event handling changes in the debug environment. Sometimes the only thing that works is to pepper my code with print statements so I can find what is actually happening just before the crash. The solution usually ends up changing callbacks to use wx.CallAfter or wx.CallLater to access widgets. Keep in mind that events are not always triggered when you think.

Brian

···

On Thursday, January 24, 2019 at 1:30:25 PM UTC-6, Ed Leafe wrote:

I’ve gotten wxPython 4 running on my Mac, but after running a bit it always crashes with output like “Segmentation fallout: 11”. I’ve stepped through my code, and it doesn’t happen at a particular line; it feels more or less random.

5

If a widget is destroyed while there are pending events for it, wx will crash later on when the event should be handled.
If your code destroys widgets, use DestroyLater which will wait until there are no more pending events.

Regards,
Dietmar

6

It’s still there. It’s just that instead of needing to use wx.PreFrame() for the first phase, you can now use wx.Frame().

···

On Friday, January 25, 2019 at 8:15:53 AM UTC-8, Ed Leafe wrote:

now that the two-phase construction is a thing of the past.

–

Robin

7

Oh? Just a name change? I must have mis-read the docs. Maybe that’s why I’m seeing these issues: I changed how the underlying wxPython object was created.

– Ed

···

On Friday, January 25, 2019 at 2:26:21 PM UTC-6, Robin Dunn wrote:

On Friday, January 25, 2019 at 8:15:53 AM UTC-8, Ed Leafe wrote:

now that the two-phase construction is a thing of the past.

It’s still there. It’s just that instead of needing to use wx.PreFrame() for the first phase, you can now use wx.Frame().

–

Robin

8

Yep, there’s a blurb about it here: wxPython Project Phoenix Migration Guide — wxPython Phoenix 4.2.2 documentation

···

On Friday, January 25, 2019 at 12:52:39 PM UTC-8, Ed Leafe wrote:

Oh? Just a name change? I must have mis-read the docs. Maybe that’s why I’m seeing these issues: I changed how the underlying wxPython object was created.

–

Robin