MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2

We get a crash on Mojave when closing a dialog above a window
drawn with/on a wxGraphicsContext.

Normal refreshes are drawn and works fine, but a refresh after a dialog
have been shown and closed on top of (above) my drawing canvas crashes every time.
Closing other windows in front of the canvas, such as wxFrame and wxMiniFrames does not trigger the crash.

My code pretty much follows the example at 

I.e. first delete 'gc' and then delete the 'dc' and then it crashes, a stack trace can be found @:

If I don't delete the 'gc' I don't get any crash, so it seems something gets deleted twice 
or is accessed after the delete?

If I don't delete the 'gc' will I leak memory?

The "canvas" is a wxScrolledWindow inside a tab/page in a wxNotebook, if that matters.

Another strange thing is that I get a wxPaint event for that notebook page even when another
page is active. So even when another page is selected/active I get the same crash when I close a dialog.
Other pages does not get a refresh event when not displayed, but they don't use wxScrolledWindows,
but that seems like another bug?

My application is written in erlang so it's not trivial for me to write an C++ example that triggers this.

When I tested this I used wxWidgets-3.0.3 built on Sierra with corresponding Xcode. 
The error report linked above says he is using wxWidgets-3.0.4, I would guess from macports or similar services.

BR
/Dan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2
Same problem with WX_3_0_branch built with latest Xcode for Mojave.


On Tue, Nov 6, 2018 at 10:17 AM Dan Gudmundsson <[hidden email]> wrote:

We get a crash on Mojave when closing a dialog above a window
drawn with/on a wxGraphicsContext.

Normal refreshes are drawn and works fine, but a refresh after a dialog
have been shown and closed on top of (above) my drawing canvas crashes every time.
Closing other windows in front of the canvas, such as wxFrame and wxMiniFrames does not trigger the crash.

My code pretty much follows the example at 

I.e. first delete 'gc' and then delete the 'dc' and then it crashes, a stack trace can be found @:

If I don't delete the 'gc' I don't get any crash, so it seems something gets deleted twice 
or is accessed after the delete?

If I don't delete the 'gc' will I leak memory?

The "canvas" is a wxScrolledWindow inside a tab/page in a wxNotebook, if that matters.

Another strange thing is that I get a wxPaint event for that notebook page even when another
page is active. So even when another page is selected/active I get the same crash when I close a dialog.
Other pages does not get a refresh event when not displayed, but they don't use wxScrolledWindows,
but that seems like another bug?

My application is written in erlang so it's not trivial for me to write an C++ example that triggers this.

When I tested this I used wxWidgets-3.0.3 built on Sierra with corresponding Xcode. 
The error report linked above says he is using wxWidgets-3.0.4, I would guess from macports or similar services.

BR
/Dan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

oneeyeman
Hi, Dan,

On Fri, Nov 9, 2018 at 2:58 AM Dan Gudmundsson <[hidden email]> wrote:

>
> Same problem with WX_3_0_branch built with latest Xcode for Mojave.
>
>
> On Tue, Nov 6, 2018 at 10:17 AM Dan Gudmundsson <[hidden email]> wrote:
>>
>>
>> We get a crash on Mojave when closing a dialog above a window
>> drawn with/on a wxGraphicsContext.
>>
>> Normal refreshes are drawn and works fine, but a refresh after a dialog
>> have been shown and closed on top of (above) my drawing canvas crashes every time.
>> Closing other windows in front of the canvas, such as wxFrame and wxMiniFrames does not trigger the crash.
>>
>> My code pretty much follows the example at
>> https://docs.wxwidgets.org/3.0/classwx_graphics_context.html
>>
>> I.e. first delete 'gc' and then delete the 'dc' and then it crashes, a stack trace can be found @:
>> https://bugs.erlang.org/browse/ERL-755
>>
>> If I don't delete the 'gc' I don't get any crash, so it seems something gets deleted twice
>> or is accessed after the delete?
>>
>> If I don't delete the 'gc' will I leak memory?
>>
>> The "canvas" is a wxScrolledWindow inside a tab/page in a wxNotebook, if that matters.
>>
>> Another strange thing is that I get a wxPaint event for that notebook page even when another
>> page is active. So even when another page is selected/active I get the same crash when I close a dialog.
>> Other pages does not get a refresh event when not displayed, but they don't use wxScrolledWindows,
>> but that seems like another bug?
>>
>> My application is written in erlang so it's not trivial for me to write an C++ example that triggers this.
>>
>> When I tested this I used wxWidgets-3.0.3 built on Sierra with corresponding Xcode.
>> The error report linked above says he is using wxWidgets-3.0.4, I would guess from macports or similar services.
''
There was couple f fixes for Mojave on master.
Can you try that?

Thank you.

>>
>> BR
>> /Dan
>
> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to [hidden email]
> or visit http://groups.google.com/group/wx-users

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Stefan Csomor
In reply to this post by Dan Gudmundsson-2
Hi

> Same problem with WX_3_0_branch built with latest Xcode for Mojave.

you definitely should not try to build a 3.0 on 10.14 / against a 10.14 SDK, there are too many changes which we try to fix on master, but for 3.0 you will need to compile against an earlier SDK, so that the compatibility layers of the OS kick in.

HTH

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2
I configure with --with-macosx-version-min=10.9   (WX_3_0.. branch doesn't build without it on Mojave SDK)

But the problem exists with the old compilation of wxWidgets that was on Sierra before upgrading to Mojave. 

Opening dialog or other windows redraw code works, close window, redraw works, close dialog redraw segfaults.

/Dan

On Fri, Nov 9, 2018 at 3:07 PM Stefan Csomor <[hidden email]> wrote:
Hi

> Same problem with WX_3_0_branch built with latest Xcode for Mojave.

you definitely should not try to build a 3.0 on 10.14 / against a 10.14 SDK, there are too many changes which we try to fix on master, but for 3.0 you will need to compile against an earlier SDK, so that the compatibility layers of the OS kick in.

HTH

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2
In reply to this post by oneeyeman

There was couple f fixes for Mojave on master.
Can you try that?

Thank you.


No that easily it seems my erlang wrapper won't build against master anymore (did a year ago or whenever I tested)..
../configure --prefix=/usr/local --with-macosx-version-min=10.9 --enable-compat28

Is no longer backwards compatible enough.. (yes I still need 2.8 compatibility, SUSE-11 uses wxWidgets-2.8.8 sigh).

gen/wxe_funcs.cpp:9506:22: error: too few arguments to function call, expected 4, have 2; did you mean 'wxMaskBase::Create'?
 bool Result = This->Create(*bitmap,colour);
                     ^~~~~~
                     wxMaskBase::Create
/ldisk/src/wxWidgets/include/wx/bitmap.h:49:10: note: 'wxMaskBase::Create' declared here
    bool Create(const wxBitmap& bitmap, const wxColour& colour);
         ^
gen/wxe_funcs.cpp:9515:22: error: too few arguments to function call, expected 4, have 2; did you mean 'wxMaskBase::Create'?
 bool Result = This->Create(*bitmap,*paletteIndex);
                     ^~~~~~
                     wxMaskBase::Create
/ldisk/src/wxWidgets/include/wx/bitmap.h:53:10: note: 'wxMaskBase::Create' declared here
    bool Create(const wxBitmap& bitmap, int paletteIndex);
         ^
gen/wxe_funcs.cpp:9523:22: error: too few arguments to function call, expected 4, have 1; did you mean 'wxMaskBase::Create'?
 bool Result = This->Create(*bitmap);
                     ^~~~~~
                     wxMaskBase::Create
/ldisk/src/wxWidgets/include/wx/bitmap.h:57:10: note: 'wxMaskBase::Create' declared here
    bool Create(const wxBitmap& bitmap);
         ^




 

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Vadim Zeitlin-4
On Fri, 9 Nov 2018 15:31:26 +0100 Dan Gudmundsson wrote:

DG> No that easily it seems my erlang wrapper won't build against master
DG> anymore (did a year ago or whenever I tested)..
DG> ../configure --prefix=/usr/local --with-macosx-version-min=10.9
DG> --enable-compat28
DG>
DG> Is no longer backwards compatible enough.. (yes I still need 2.8
DG> compatibility, SUSE-11 uses wxWidgets-2.8.8 sigh).
DG>
DG> gen/wxe_funcs.cpp:9506:22: error: too few arguments to function call,
DG> expected 4, have 2; did you mean 'wxMaskBase::Create'?
DG>  bool Result = This->Create(*bitmap,colour);
DG>                      ^~~~~~
DG>                      wxMaskBase::Create

 This was broken in e7d21f6638a6d5f715bea5dcef461f9d19e4d979 which just
removed the 2 other overloads and I think it was just an oversight, i.e. it
just hid the other Create() overloads by adding the Mac-specific one it
added.

 I've created https://github.com/wxWidgets/wxWidgets/pull/1019 fixing this,
please let us know if you still have any troubles if you use it.

 And thanks for reporting this breakage,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2

Thanks VZ
The PR fixed my build issues.

Same problem though with that branch tough..
* thread #1, stop reason = signal SIGSTOP
 * frame #0: 0x00007fff70f58b86 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff7100ec50 libsystem_pthread.dylib`pthread_kill + 285
    frame #2: 0x00007fff70ec21c9 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff70e8a868 libsystem_c.dylib`__assert_rtn + 320
    frame #4: 0x00007fff441bb34e CoreGraphics`CGGStackRestore + 143
    frame #5: 0x00007fff441bb29f CoreGraphics`CGContextRestoreGState + 32
    frame #6: 0x0000000062409952 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxMacCoreGraphicsContext::~wxMacCoreGraphicsContext() + 34
    frame #7: 0x0000000062409a0f libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxMacCoreGraphicsContext::~wxMacCoreGraphicsContext() + 15
    frame #8: 0x0000000062009193 wxe_driver.so`WxeApp::delete_object(this=<unavailable>, ptr=0x00007fe132c442b0, refd=<unavailable>) at wxe_funcs.cpp:32177 [opt]
    frame #9: 0x0000000061f8b175 wxe_driver.so`WxeApp::wxe_dispatch(this=0x00007fe130414cb0, Ecmd=0x0000000060741b68) at wxe_funcs.cpp:57 [opt]
    frame #10: 0x0000000061f8390b wxe_driver.so`WxeApp::dispatch_cmds(this=0x00007fe130414cb0) at wxe_impl.cpp:253 [opt]
    frame #11: 0x0000000061f82be2 wxe_driver.so`WxeApp::idle(this=<unavailable>, event=0x00007ffee04109d0) at wxe_impl.cpp:203 [opt]
    frame #12: 0x0000000062c1035b libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 283
    frame #13: 0x0000000062c1007b libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEventLocally(wxEvent&) + 59
    frame #14: 0x0000000062c0ff34 libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEvent(wxEvent&) + 100
    frame #15: 0x0000000062afcbfa libwx_baseu-3.1.2.0.0.dylib`wxAppConsoleBase::ProcessIdle() + 74




On Fri, Nov 9, 2018 at 5:01 PM Vadim Zeitlin <[hidden email]> wrote:
On Fri, 9 Nov 2018 15:31:26 +0100 Dan Gudmundsson wrote:

DG> No that easily it seems my erlang wrapper won't build against master
DG> anymore (did a year ago or whenever I tested)..
DG> ../configure --prefix=/usr/local --with-macosx-version-min=10.9
DG> --enable-compat28
DG>
DG> Is no longer backwards compatible enough.. (yes I still need 2.8
DG> compatibility, SUSE-11 uses wxWidgets-2.8.8 sigh).
DG>
DG> gen/wxe_funcs.cpp:9506:22: error: too few arguments to function call,
DG> expected 4, have 2; did you mean 'wxMaskBase::Create'?
DG>  bool Result = This->Create(*bitmap,colour);
DG>                      ^~~~~~
DG>                      wxMaskBase::Create

 This was broken in e7d21f6638a6d5f715bea5dcef461f9d19e4d979 which just
removed the 2 other overloads and I think it was just an oversight, i.e. it
just hid the other Create() overloads by adding the Mac-specific one it
added.

 I've created https://github.com/wxWidgets/wxWidgets/pull/1019 fixing this,
please let us know if you still have any troubles if you use it.

 And thanks for reporting this breakage,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2
Hmm I didn't have the time todo a clean rebuild if that changes anything.
Will retry after a git clean on Monday.

On Fri, Nov 9, 2018 at 5:55 PM Dan Gudmundsson <[hidden email]> wrote:

Thanks VZ
The PR fixed my build issues.

Same problem though with that branch tough..
* thread #1, stop reason = signal SIGSTOP
 * frame #0: 0x00007fff70f58b86 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff7100ec50 libsystem_pthread.dylib`pthread_kill + 285
    frame #2: 0x00007fff70ec21c9 libsystem_c.dylib`abort + 127
    frame #3: 0x00007fff70e8a868 libsystem_c.dylib`__assert_rtn + 320
    frame #4: 0x00007fff441bb34e CoreGraphics`CGGStackRestore + 143
    frame #5: 0x00007fff441bb29f CoreGraphics`CGContextRestoreGState + 32
    frame #6: 0x0000000062409952 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxMacCoreGraphicsContext::~wxMacCoreGraphicsContext() + 34
    frame #7: 0x0000000062409a0f libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxMacCoreGraphicsContext::~wxMacCoreGraphicsContext() + 15
    frame #8: 0x0000000062009193 wxe_driver.so`WxeApp::delete_object(this=<unavailable>, ptr=0x00007fe132c442b0, refd=<unavailable>) at wxe_funcs.cpp:32177 [opt]
    frame #9: 0x0000000061f8b175 wxe_driver.so`WxeApp::wxe_dispatch(this=0x00007fe130414cb0, Ecmd=0x0000000060741b68) at wxe_funcs.cpp:57 [opt]
    frame #10: 0x0000000061f8390b wxe_driver.so`WxeApp::dispatch_cmds(this=0x00007fe130414cb0) at wxe_impl.cpp:253 [opt]
    frame #11: 0x0000000061f82be2 wxe_driver.so`WxeApp::idle(this=<unavailable>, event=0x00007ffee04109d0) at wxe_impl.cpp:203 [opt]
    frame #12: 0x0000000062c1035b libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 283
    frame #13: 0x0000000062c1007b libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEventLocally(wxEvent&) + 59
    frame #14: 0x0000000062c0ff34 libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEvent(wxEvent&) + 100
    frame #15: 0x0000000062afcbfa libwx_baseu-3.1.2.0.0.dylib`wxAppConsoleBase::ProcessIdle() + 74




On Fri, Nov 9, 2018 at 5:01 PM Vadim Zeitlin <[hidden email]> wrote:
On Fri, 9 Nov 2018 15:31:26 +0100 Dan Gudmundsson wrote:

DG> No that easily it seems my erlang wrapper won't build against master
DG> anymore (did a year ago or whenever I tested)..
DG> ../configure --prefix=/usr/local --with-macosx-version-min=10.9
DG> --enable-compat28
DG>
DG> Is no longer backwards compatible enough.. (yes I still need 2.8
DG> compatibility, SUSE-11 uses wxWidgets-2.8.8 sigh).
DG>
DG> gen/wxe_funcs.cpp:9506:22: error: too few arguments to function call,
DG> expected 4, have 2; did you mean 'wxMaskBase::Create'?
DG>  bool Result = This->Create(*bitmap,colour);
DG>                      ^~~~~~
DG>                      wxMaskBase::Create

 This was broken in e7d21f6638a6d5f715bea5dcef461f9d19e4d979 which just
removed the 2 other overloads and I think it was just an oversight, i.e. it
just hid the other Create() overloads by adding the Mac-specific one it
added.

 I've created https://github.com/wxWidgets/wxWidgets/pull/1019 fixing this,
please let us know if you still have any troubles if you use it.

 And thanks for reporting this breakage,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Stefan Csomor
Hi Dan,

Mojave sends early repaints, I thought this would only be for apps linked against 10.14, but your description of early paints for notebook pages etc. sounds as if the same is happening in your 10.12 SDK build. This was/should have been fixed on master. Is this still happening for you when building against 10.14 SDK with current master ?

Best,

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2
Stefan, that is what I believe, I'll have to double check on Monday, I borrow a mac-mini at work.

The backtrace posted above was built with Vadim's PullRequest, I guess that was based on a late master? I didn't check.
And I believe the latest SDK is installed, we have upgraded to Mojave and re-installed xcode,
but I didn't do it personally and have not checked the version.

In my original test I used, wxWidgets-3.0.3 (built with 10.12) and linked to my app built with the new xcode.



On Fri, Nov 9, 2018 at 6:29 PM Stefan Csomor <[hidden email]> wrote:
Hi Dan,

Mojave sends early repaints, I thought this would only be for apps linked against 10.14, but your description of early paints for notebook pages etc. sounds as if the same is happening in your 10.12 SDK build. This was/should have been fixed on master. Is this still happening for you when building against 10.14 SDK with current master ?

Best,

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Stefan Csomor
Hi Dan

➢ In my original test I used, wxWidgets-3.0.3 (built with 10.12) and linked to my app built with the new xcode.

I think this might be a situation where indeed SDK 10.14 is burnt into the info.plist of the created app. So to really get compatibility you’d need to link the resulting app against a SDK < 10.14

Thanks,

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2

Oh, erlang is console based and the gui apps are debuggers and system performance monitoring applications started
from the console. There are no plists here, I use TransformProcessType(&psn, kProcessTransformToForegroundApplication);
to bootstrap the gui system.

if you who know something about the mac could take a brief glance it would be appreciated.


On Sat, Nov 10, 2018 at 9:37 AM Stefan Csomor <[hidden email]> wrote:
Hi Dan

➢ In my original test I used, wxWidgets-3.0.3 (built with 10.12) and linked to my app built with the new xcode.

I think this might be a situation where indeed SDK 10.14 is burnt into the info.plist of the created app. So to really get compatibility you’d need to link the resulting app against a SDK < 10.14

Thanks,

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Stefan Csomor
Hi

>Oh, erlang is console based and the gui apps are debuggers and system performance monitoring applications started
>from the console. There are no plists here, I use TransformProcessType(&psn, kProcessTransformToForegroundApplication);
>to bootstrap the gui system.

There is an option for Xcode builds named CREATE_INFOPLIST_SECTION_IN_BINARY which would allow including an info.plist in the binary, then the binary behaves like the ordinary bundle and carries all the keys like DTSDKBuild with it, perhaps this would allow to trigger a better compatibility

eg when I build a command line tool and change the build parameter I can ask using

NSLog( @"%@", [ NSBundle mainBundle ].infoDictionary );

and get e.g.

TestConsolePlist[18873:9132228] {
    BuildMachineOSBuild = 17G65;
    CFBundleDevelopmentRegion = en;
    CFBundleExecutable = TestConsolePlist;
    CFBundleInfoDictionaryVersion = "6.0";
    CFBundleName = TestConsolePlist;
    CFBundlePackageType = APPL;
    CFBundleShortVersionString = "1.0";
    CFBundleSupportedPlatforms =     (
        MacOSX
    );
    CFBundleVersion = 1;
    DTCompiler = "com.apple.compilers.llvm.clang.1_0";
    DTPlatformBuild = 10B61;
    DTPlatformVersion = GM;
    DTSDKBuild = 18B71;
    DTSDKName = "macosx10.14";
    DTXcode = 1010;
    DTXcodeBuild = 10B61;
    LSMinimumSystemVersion = "10.13";
    NSHumanReadableCopyright = "Copyright \U00a9 2018 Stefan Csomor. All rights reserved.";
    NSMainStoryboardFile = Main;
    NSPrincipalClass = NSApplication;
}

Best,

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[4]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Vadim Zeitlin-4
On Sat, 10 Nov 2018 14:27:34 +0000 Stefan Csomor wrote:

SC> There is an option for Xcode builds named
SC> CREATE_INFOPLIST_SECTION_IN_BINARY which would allow including an
SC> info.plist in the binary

 This seems useful. Would you know how to do it from the command line? I.e.
what does the link command look like if you use this option in Xcode?

 Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Stefan Csomor
Hi
 
    SC> There is an option for Xcode builds named
    SC> CREATE_INFOPLIST_SECTION_IN_BINARY which would allow including an
    SC> info.plist in the binary
   
     This seems useful. Would you know how to do it from the command line? I.e.
    what does the link command look like if you use this option in Xcode?
   
If you are using the GUI, the setting is in "Packaging" named "Create Info.plist Section in Binary", if you are using the command line you can include arbitrary elements using the linker command -sectcreate segname sectname file

sectname (section) would be __info_plist, segname (segment) would be __TEXT, file the path to the Info.plist

to pipe this through from clang would be using -Wl,option ... :

-Wl,-sectcreate,__TEXT,__info_plist,path/to/Info.plist

Best,

Stefan

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2
In reply to this post by Vadim Zeitlin-4
Erlang have a wrapper api for wxWidgets in dynamic library loaded only when any graphics is required.
I'm not sure I understand is that something I can build into that dynamic library?
Any pointers to documentation?

The "hack" above have worked since I wrote the wrapper library years ago, 
but I try to keep the development to a minimum since it's mostly me maintaining the wrapper and the gui apps
for erlang and it's not my main work area.

I also use wxWidgets wrapper for Wings3D on my hobby project :-) so it would be good if continued to work
even if OpenGL have been deprecated on mac.


On Sat, Nov 10, 2018 at 3:41 PM Vadim Zeitlin <[hidden email]> wrote:
On Sat, 10 Nov 2018 14:27:34 +0000 Stefan Csomor wrote:

SC> There is an option for Xcode builds named
SC> CREATE_INFOPLIST_SECTION_IN_BINARY which would allow including an
SC> info.plist in the binary

 This seems useful. Would you know how to do it from the command line? I.e.
what does the link command look like if you use this option in Xcode?

 Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[6]: Embedding Info.plist (was: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4)

Vadim Zeitlin-4
In reply to this post by Stefan Csomor
On Sat, 10 Nov 2018 16:21:14 +0000 Stefan Csomor wrote:

SC> Hi
SC>  
SC>     SC> There is an option for Xcode builds named
SC>     SC> CREATE_INFOPLIST_SECTION_IN_BINARY which would allow including an
SC>     SC> info.plist in the binary
SC>    
SC>      This seems useful. Would you know how to do it from the command line? I.e.
SC>     what does the link command look like if you use this option in Xcode?
SC>    
SC> If you are using the GUI,

 Well, it's me we're speaking about, so the answer is "not if I can help
it" :-)

SC> the setting is in "Packaging" named "Create Info.plist Section in
SC> Binary", if you are using the command line you can include arbitrary
SC> elements using the linker command -sectcreate segname sectname file
SC>
SC> sectname (section) would be __info_plist, segname (segment) would be
SC> __TEXT, file the path to the Info.plist

 Great, thanks, this will certainly be useful.

 Just one last question: is using a separate Info.plist still preferable
for GUI/bundled applications or should we use this section for them too?

 Thanks again,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re[6]: Embedding Info.plist (was: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4)

Stefan Csomor
Hi
 
     Just one last question: is using a separate Info.plist still preferable
    for GUI/bundled applications or should we use this section for them too?

yes, separate file is preferred, btw. I just tested and found out that our command line builds don't set these build flags at all, it's just the plain Info.plist content. I have not found a way yet to set this on command lines builds short of using xcodebuild and Xcode projects.

I also have not found reliable information about which data is used by the compatibility modes, whether it uses version info of the fameworks linked against or whether it used DTSDKBuild etc.

Best,

Stefan

 

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: MacOsX Mojave ~wxGraphicsContext Crash wxWidgets-3.0.3 and wxWidgets-3.0.4

Dan Gudmundsson-2
In reply to this post by Dan Gudmundsson-2
I did a total rebuild from latest master (commit 65ac801c400c)

And I still see the problem.

Xcode is version 10.1 
[jubilee:/ldisk/src/wxWidgets/WX31/samples]> cc --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I don't know how to find the SDK version.

I compiled the samples and got two crashes when testing the drawing sample.
Not the same as my but for your information.
The first one from shortcut F5 or F6 
The second after double clicking and right clicking with the mouse or just trying out different things in the sample.
They are both reproducible but I don't know what triggers the second crash.


[jubilee:/ldisk/src/wxWidgets/WX31/samples]> drawing/drawing
09:20:20 AM: Debug: Adding duplicate image handler for 'PNG file'
../src/common/dcgraph.cpp(1019): assert ""Assert failure"" failed in DoStretchBlit(): Blitting is not supported with this logical operation.
Collecting stack trace information, please wait...Trace/BPT trap: 5 (core dumped)
[jubilee:/ldisk/src/wxWidgets/WX31/samples]> lldb drawing/drawing -c core.41055 
(lldb) target create "drawing/drawing" --core "core.41055"
Core file '/ldisk/src/wxWidgets/WX31/samples/core.41055' (x86_64) was loaded.
(lldb) bt
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x000000010f6dc4c4 libwx_baseu-3.1.2.0.0.dylib`wxDefaultAssertHandler(wxString const&, int, wxString const&, wxString const&, wxString const&) + 116
    frame #1: 0x000000010f6da1ac libwx_baseu-3.1.2.0.0.dylib`wxOnAssert(char const*, int, char const*, char const*, char const*) + 124
    frame #2: 0x000000010f044253 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxGUIEventLoop::~wxGUIEventLoop() + 195
    frame #3: 0x000000010ef8dd06 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxDialog::ShowModal() + 182
    frame #4: 0x000000010f1c4608 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxGenericMessageDialog::ShowModal() + 56
    frame #5: 0x000000010f08ce37 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxGUIAppTraitsBase::ShowAssertDialog(wxString const&) + 519
    frame #6: 0x000000010f6dbbdd libwx_baseu-3.1.2.0.0.dylib`ShowAssertDialog(wxString const&, int, wxString const&, wxString const&, wxString const&, wxAppTraits*) + 813
    frame #7: 0x000000010f6db720 libwx_baseu-3.1.2.0.0.dylib`wxAppConsoleBase::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*) + 352
    frame #8: 0x000000010f6dc562 libwx_baseu-3.1.2.0.0.dylib`wxDefaultAssertHandler(wxString const&, int, wxString const&, wxString const&, wxString const&) + 274
    frame #9: 0x000000010f6d963c libwx_baseu-3.1.2.0.0.dylib`wxOnAssert(char const*, int, char const*, char const*, wchar_t const*) + 172
    frame #10: 0x000000010f0b36c8 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxGCDCImpl::DoStretchBlit(int, int, int, int, wxDC*, int, int, int, int, wxRasterOperationMode, bool, int, int) + 328
    frame #11: 0x000000010f0b356c libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxGCDCImpl::DoBlit(int, int, int, int, wxDC*, int, int, wxRasterOperationMode, bool, int, int) + 60
    frame #12: 0x000000010ef43ef8 drawing`MyCanvas::DrawImages(wxDC&, MyCanvas::DrawMode) + 792
    frame #13: 0x000000010ef4a772 drawing`MyCanvas::Draw(wxDC&) + 1266
    frame #14: 0x000000010ef4005b drawing`MyCanvas::OnPaint(wxPaintEvent&) + 91
    frame #15: 0x000000010f7ebb20 libwx_baseu-3.1.2.0.0.dylib`wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 464
    frame #16: 0x000000010f7ed09d libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEventLocally(wxEvent&) + 93
    frame #17: 0x000000010f7ecf34 libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEvent(wxEvent&) + 100
    frame #18: 0x000000010f1cf242 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) + 34
    frame #19: 0x000000010f7ed67c libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::SafelyProcessEvent(wxEvent&) + 12
    frame #20: 0x000000010ef9b8f6 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxWindow::MacDoRedraw(long) + 710
    frame #21: 0x000000010f065cd4 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxWidgetCocoaImpl::drawRect(void*, NSView*, void*) + 740
    frame #22: 0x000000010f063bd6 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxOSX_drawRect(NSView*, objc_selector*, CGRect) + 86
    frame #23: 0x00007fff41407205 AppKit`_NSViewDrawRect + 66
    frame #24: 0x00007fff41405abd AppKit`-[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inContext:shouldChangeFontReferenceColor:stopAtLayerBackedViews:] + 1545
    frame #25: 0x00007fff41405ebb AppKit`-[NSView(NSInternal) _recursive:displayRectIgnoringOpacity:inContext:shouldChangeFontReferenceColor:stopAtLayerBackedViews:] + 2567
    frame #26: 0x00007fff414054a2 AppKit`__46-[NSView(NSLayerKitGlue) drawLayer:inContext:]_block_invoke + 192
    frame #27: 0x00007fff41405201 AppKit`-[NSView(NSLayerKitGlue) _drawViewBackingLayer:inContext:drawingHandler:] + 1769
    frame #28: 0x00007fff4ed19aaf QuartzCore`CABackingStoreUpdate_ + 577
    frame #29: 0x00007fff4ed7b325 QuartzCore`___ZN2CA5Layer8display_Ev_block_invoke + 53
    frame #30: 0x00007fff4ed18c90 QuartzCore`-[CALayer _display] + 1839
    frame #31: 0x00007fff4140475a AppKit`_NSBackingLayerDisplay + 531
    frame #32: 0x00007fff413e8cc9 AppKit`-[_NSViewBackingLayer display] + 811
    frame #33: 0x00007fff4ed181bc QuartzCore`CA::Layer::display_if_needed(CA::Transaction*) + 634
    frame #34: 0x00007fff4ed06447 QuartzCore`CA::Context::commit_transaction(CA::Transaction*) + 319
    frame #35: 0x00007fff4ed05d20 QuartzCore`CA::Transaction::commit() + 576
    frame #36: 0x00007fff413df8f5 AppKit`__65+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayRefresh]_block_invoke + 274
    frame #37: 0x00007fff43de395d CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
    frame #38: 0x00007fff43de3892 CoreFoundation`__CFRunLoopDoObservers + 452
    frame #39: 0x00007fff43d853c5 CoreFoundation`__CFRunLoopRun + 1166
    frame #40: 0x00007fff43d84ce4 CoreFoundation`CFRunLoopRunSpecific + 463
    frame #41: 0x00007fff4301e895 HIToolbox`RunCurrentEventLoopInMode + 293
    frame #42: 0x00007fff4301e4d4 HIToolbox`ReceiveNextEventCommon + 371
    frame #43: 0x00007fff4301e348 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 64
    frame #44: 0x00007fff412db95b AppKit`_DPSNextEvent + 997
    frame #45: 0x00007fff412da6fa AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1362
    frame #46: 0x00007fff412d475d AppKit`-[NSApplication run] + 699
    frame #47: 0x000000010f0445df libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxGUIEventLoop::OSXDoRun() + 207
    frame #48: 0x000000010f7c25d1 libwx_baseu-3.1.2.0.0.dylib`wxCFEventLoop::DoRun() + 49
    frame #49: 0x000000010f70b96e libwx_baseu-3.1.2.0.0.dylib`wxEventLoopBase::Run() + 158
    frame #50: 0x000000010f6d9923 libwx_baseu-3.1.2.0.0.dylib`wxAppConsoleBase::MainLoop() + 99
    frame #51: 0x000000010efd814a libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxApp::OnRun() + 26
    frame #52: 0x000000010f7451c3 libwx_baseu-3.1.2.0.0.dylib`wxEntry(int&, wchar_t**) + 131
    frame #53: 0x000000010ef3f204 drawing`main + 20
    frame #54: 0x00007fff70e1a085 libdyld.dylib`start + 1
(lldb) q
[jubilee:/ldisk/src/wxWidgets/WX31/samples]> drawing/drawing
09:22:40 AM: Debug: Adding duplicate image handler for 'PNG file'
Segmentation fault: 11 (core dumped)
[jubilee:/ldisk/src/wxWidgets/WX31/samples]> lldb drawing/drawing -c core.41125 
(lldb) target create "drawing/drawing" --core "core.41125"
Core file '/ldisk/src/wxWidgets/WX31/samples/core.41125' (x86_64) was loaded.
(lldb) bt
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x00007fff6fd3da57 libobjc.A.dylib`objc_msgSend + 87
    frame #1: 0x00007fff441c8833 CoreGraphics`CGContextRetain + 22
    frame #2: 0x000000010b81fecc libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxMacCoreGraphicsContext::SetNativeContext(CGContext*) + 156
    frame #3: 0x000000010b81fd4c libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxMacCoreGraphicsContext::wxMacCoreGraphicsContext(wxGraphicsRenderer*, CGContext*, double, double, wxWindow*) + 124
    frame #4: 0x000000010b822f93 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxMacCoreGraphicsRenderer::CreateContextFromNativeContext(void*) + 51
    frame #5: 0x000000010b8a7b3f libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxOverlayImpl::BeginDrawing(wxDC*) + 111
    frame #6: 0x000000010b97978f libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxDCOverlay::wxDCOverlay(wxOverlay&, wxDC*) + 207
    frame #7: 0x000000010b77c2e5 drawing`MyCanvas::OnMouseMove(wxMouseEvent&) + 421
    frame #8: 0x000000010c026b20 libwx_baseu-3.1.2.0.0.dylib`wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) + 464
    frame #9: 0x000000010c02809d libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEventLocally(wxEvent&) + 93
    frame #10: 0x000000010c027f34 libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::ProcessEvent(wxEvent&) + 100
    frame #11: 0x000000010ba0b242 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxScrollHelperEvtHandler::ProcessEvent(wxEvent&) + 34
    frame #12: 0x000000010c02867c libwx_baseu-3.1.2.0.0.dylib`wxEvtHandler::SafelyProcessEvent(wxEvent&) + 12
    frame #13: 0x000000010b8a57d9 libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxWidgetCocoaImpl::DoHandleMouseEvent(NSEvent*) + 89
    frame #14: 0x000000010b88af86 libwx_osx_cocoau_core-3.1.2.0.0.dylib`-[NSWindow(wxNSWindowSupport) WX_filterSendEvent:] + 150
    frame #15: 0x000000010b88afd0 libwx_osx_cocoau_core-3.1.2.0.0.dylib`-[wxNSWindow sendEvent:] + 32
    frame #16: 0x00007fff412e6f4c AppKit`-[NSApplication(NSEvent) sendEvent:] + 336
    frame #17: 0x000000010b7c7142 libwx_osx_cocoau_core-3.1.2.0.0.dylib`-[wxNSApplication sendEvent:] + 98
    frame #18: 0x00007fff412d4795 AppKit`-[NSApplication run] + 755
    frame #19: 0x000000010b8805df libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxGUIEventLoop::OSXDoRun() + 207
    frame #20: 0x000000010bffd5d1 libwx_baseu-3.1.2.0.0.dylib`wxCFEventLoop::DoRun() + 49
    frame #21: 0x000000010bf4696e libwx_baseu-3.1.2.0.0.dylib`wxEventLoopBase::Run() + 158
    frame #22: 0x000000010bf14923 libwx_baseu-3.1.2.0.0.dylib`wxAppConsoleBase::MainLoop() + 99
    frame #23: 0x000000010b81414a libwx_osx_cocoau_core-3.1.2.0.0.dylib`wxApp::OnRun() + 26
    frame #24: 0x000000010bf801c3 libwx_baseu-3.1.2.0.0.dylib`wxEntry(int&, wchar_t**) + 131
    frame #25: 0x000000010b77b204 drawing`main + 20
    frame #26: 0x00007fff70e1a085 libdyld.dylib`start + 1


On Sat, Nov 10, 2018 at 5:22 PM Dan Gudmundsson <[hidden email]> wrote:
Erlang have a wrapper api for wxWidgets in dynamic library loaded only when any graphics is required.
I'm not sure I understand is that something I can build into that dynamic library?
Any pointers to documentation?

The "hack" above have worked since I wrote the wrapper library years ago, 
but I try to keep the development to a minimum since it's mostly me maintaining the wrapper and the gui apps
for erlang and it's not my main work area.

I also use wxWidgets wrapper for Wings3D on my hobby project :-) so it would be good if continued to work
even if OpenGL have been deprecated on mac.


On Sat, Nov 10, 2018 at 3:41 PM Vadim Zeitlin <[hidden email]> wrote:
On Sat, 10 Nov 2018 14:27:34 +0000 Stefan Csomor wrote:

SC> There is an option for Xcode builds named
SC> CREATE_INFOPLIST_SECTION_IN_BINARY which would allow including an
SC> info.plist in the binary

 This seems useful. Would you know how to do it from the command line? I.e.
what does the link command look like if you use this option in Xcode?

 Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
12