Crash when trying to erase entry in gs_nativeImages (Issue #22862)
Mark Whalley
MacOS 12.6 / WX3.2.1
Access violation when trying to erase entry from the gs_nativeImages map
called from here:
It is being called with an impl that is not in the map (called with 0x0000000130d086e0)
when gs_nativeImages only holds the following two entries:
Not sure if exception is that an entry will always exist or we should check first, but obviously something going wrong.
Not had chance to replicate in small application I can share, but thought I would raise whilst I get time to do this,
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
Though not quite sure why this should crash as the erase should just return the fact that nothing has been erased.....
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Could you please copy-and-paste the stack trace at the moment of the crash? This would give us at least something to work with.
Also please try rebuilding the project using ASAN, this should give much more useful information about the crash. If you really can't do this, perhaps try running it under valgrid.
But as it is it's simply impossible to do anything about this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
@vadz Having refactored the application code the issue no longer seems to be there, so I'm unable to reproduce. Going to close for now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
Closed #22862 as completed.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
Spoke too soon.. Issue is still there. Will see what I can do to provide more info.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
Reopened #22862.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
Stack trace
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xa0)
* frame #0: 0x00000001018badcc mmex`std::__1::__hash_iterator<std::__1::__hash_node<std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>, void*>*> std::__1::__hash_table<std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>, std::__1::__unordered_map_hasher<wxBitmapBundleImpl const*, std::__1::__hash_value_type<wxBitmapBundleImpl const*, (this=0x0000000102868bb0, __k=0x000000016fdff108)::wxOSXImageHolder>, std::__1::hash<wxBitmapBundleImpl const*>, std::__1::equal_to<wxBitmapBundleImpl const*>, true>, std::__1::__unordered_map_equal<wxBitmapBundleImpl const*, std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>, std::__1::equal_to<wxBitmapBundleImpl const*>, std::__1::hash<wxBitmapBundleImpl const*>, true>, std::__1::allocator<std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>>>::find<wxBitmapBundleImpl const*>(wxBitmapBundleImpl const* const&) at __hash_table:2394:31
frame #1: 0x00000001018bd06c mmex`unsigned long std::__1::__hash_table<std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>, std::__1::__unordered_map_hasher<wxBitmapBundleImpl const*, std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>, std::__1::hash<wxBitmapBundleImpl const*>, std::__1::equal_to<wxBitmapBundleImpl const*>, true>, std::__1::__unordered_map_equal<wxBitmapBundleImpl const*, std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>, std::__1::equal_to<wxBitmapBundleImpl const*>, std::__1::hash<wxBitmapBundleImpl const*>, true>, std::__1::allocator<std::__1::__hash_value_type<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder>>>::__erase_unique<wxBitmapBundleImpl const*>(this=0x0000000102868bb0, __k=0x000000016fdff108) at __hash_table:2533:20
frame #2: 0x00000001018b8f7c mmex`std::__1::unordered_map<wxBitmapBundleImpl const*, (anonymous namespace)::wxOSXImageHolder, std::__1::hash<wxBitmapBundleImpl const*>, std::__1::equal_to<wxBitmapBundleImpl const*>, std::__1::allocator<std::__1::pair<wxBitmapBundleImpl const* const, (anonymous namespace)::wxOSXImageHolder>>>::erase(this=0x0000000102868bb0 size=5, __k=0x000000016fdff108) at unordered_map:1272:59
frame #3: 0x00000001018b8f50 mmex`wxOSXBundleImplDestroyed(impl=0x0000000115799bc0) at bmpbndl.mm:99:21
frame #4: 0x0000000101b58dc4 mmex`wxBitmapBundleImpl::~wxBitmapBundleImpl(this=0x0000000115799bc0) at bmpbndl.cpp:843:5
frame #5: 0x0000000101b6cf14 mmex`(anonymous namespace)::wxBitmapBundleImplSVG::~wxBitmapBundleImplSVG(this=0x0000000115799bc0) at bmpsvg.cpp:116:5
frame #6: 0x0000000101b6cd18 mmex`(anonymous namespace)::wxBitmapBundleImplSVG::~wxBitmapBundleImplSVG(this=0x0000000115799bc0) at bmpsvg.cpp:113:5
frame #7: 0x0000000101b6cd44 mmex`(anonymous namespace)::wxBitmapBundleImplSVG::~wxBitmapBundleImplSVG(this=0x0000000115799bc0) at bmpsvg.cpp:113:5
frame #8: 0x0000000101c0eaf4 mmex`wxRefCounter::DecRef(this=0x0000000115799bc0) at object.cpp:339:9
frame #9: 0x0000000101b5c764 mmex`wxObjectDataPtr<wxBitmapBundleImpl>::~wxObjectDataPtr(this=0x0000000107395270) at object.h:293:20
frame #10: 0x0000000101b57638 mmex`wxObjectDataPtr<wxBitmapBundleImpl>::~wxObjectDataPtr(this=0x0000000107395270) at object.h:291:5
frame #11: 0x0000000101b5760c mmex`wxBitmapBundle::~wxBitmapBundle(this=0x0000000107395270) at bmpbndl.cpp:402:1
frame #12: 0x0000000101b56c20 mmex`wxBitmapBundle::~wxBitmapBundle(this=0x0000000107395270) at bmpbndl.cpp:401:1
frame #13: 0x000000010057dbac mmex`wxSharedPtr<wxBitmapBundle>::reftype::delete_ptr(this=0x000000011befc1f0) at sharedptr.h:119:37
frame #14: 0x000000010057dd38 mmex`wxSharedPtr<wxBitmapBundle>::Release(this=0x000000010285b2f8) at sharedptr.h:149:24
frame #15: 0x000000010057dbe0 mmex`wxSharedPtr<wxBitmapBundle>::~wxSharedPtr(this=0x000000010285b2f8) at sharedptr.h:41:48
frame #16: 0x000000010055597c mmex`wxSharedPtr<wxBitmapBundle>::~wxSharedPtr(this=0x000000010285b2f8) at sharedptr.h:41:46
frame #17: 0x00000001005909a0 mmex`::__cxx_global_array_dtor.143((null)=0x0000000000000000) at images_list.cpp:0
frame #18: 0x00000001a2fa7dd0 libsystem_c.dylib`__cxa_finalize_ranges + 464
frame #19: 0x00000001a2fa7b74 libsystem_c.dylib`exit + 44
frame #20: 0x00000001a30c8ec4 libdyld.dylib`dyld4::LibSystemHelpers::exit(int) const + 20
frame #21: 0x0000000104d310d8 dyld`start + 596
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It looks like you're creating a global variable containing bitmap (bundles). This is not, and won't be, supported, you can create GUI objects only after initializing the GUI (and have to delete them before shutting it down), i.e. do it in YourApp::OnInit()/OnExit().
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #22862 as not planned.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
@vadz - Thanks for the advice, yes it is a global. We had previously been using wxBitmap's in the app but have moved to bundles. Will look to refactor based on your advice.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
Does it matter that these bundles, whilst stored as globals ARE created once the App is initialised?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It's really surprising that you didn't have any problems with global bitmaps with wxGTK, destroying them after closing connection to the X server should have resulted in problems as well.
Creating them after initializing the app is required but not sufficient, they must also be destroyed before it is shut down.
To be totally fair, we might be able to make using globals work with wxMSW and wxOSX where the GUI is always available, but this is really impossible with wxGTK where the GUI is initialized/shut down as part of wxApp initialization/destruction, and as we want to encourage people writing portable code, it doesn't seem wise to spend efforts on making this work under non-Unix platforms.
Although having an assert rather than a crash would be preferable, of course...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mark Whalley
they must also be destroyed before it is shut down.
Gotcha.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Gerhard Stein
Hi,
I tested this with money manager ex on my machine.
At least I did not run into any crashes and I left the program running with gdb, so I would catch everything that should throw signals, exceptions, etc.. Not sure if exceptions in general can do something it between I might oversee using gdb. I can check whether these global wxBitmapBundles can be moved to a proper class (I'd prefer that anyways). I could imagine that way we would not have to deal with race conditions, when the app destructor is running while the application closes.
Just a side note, not sure if related, I am using Wayland. Maybe that is why it never crashed on my side. I don't know...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.