Cocoa Port hangs in init

[Dan Gudmundsson]

Hi guys I have a problem with the current versions.

The erlang port hangs during initialization om mac (snow leopard),

since commit (git) b0fa6efc8

    using #ifdef wxABORT_ON_CONFIG_ERROR not just #if as elsewhere

    

    git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74656 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

Backtrace is:

#0  0x00007fff8a605d7a in mach_msg_trap ()

#1  0x00007fff8a6063ed in mach_msg ()

#2  0x00007fff81bb1902 in __CFRunLoopRun ()

#3  0x00007fff81bb0d8f in CFRunLoopRunSpecific ()

#4  0x00007fff808da7ee in RunCurrentEventLoopInMode ()

#5  0x00007fff808da5f3 in ReceiveNextEventCommon ()

#6  0x00007fff808da4ac in BlockUntilNextEventMatchingListInMode ()

#7  0x00007fff8877eeb2 in _DPSNextEvent ()

#8  0x00007fff8877e801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()

#9  0x00007fff8874468f in -[NSApplication run] ()

#10 0x0000000013c9dfa8 in wxGUIEventLoop::OSXDoRun ()

#11 0x0000000014438ddf in wxCFEventLoop::DoRun ()

#12 0x00000000143777e1 in wxEventLoopBase::Run ()

#13 0x000000001433bfa7 in wxAppConsoleBase::MainLoop ()

#14 0x0000000013c30147 in wxApp::OnRun ()

#15 0x00000000143b5393 in wxEntry ()

#16 0x0000000013181c5b in wxe_main_loop (vpdl=0x11c823f8) at wxe_impl.cpp:237

#17 0x00000000100259bb in erl_start (argc=<value temporarily unavailable, due to optimizations>, argv=0x7fff5fbfef20) at beam/erl_init.c:1775

Took me a day to find that commit, on my old and slow mac mini via a manual bisect.

Is it something I have change to make it work or is that bug wxWidgets?

Regards

/Dan

[Vadim Zeitlin]

On Thu, 12 Sep 2013 10:51:31 +0200 Dan Gudmundsson wrote:

DG> Hi guys I have a problem with the current versions.

Hello,

Sorry for the lack of reply, I hoped Stefan would answer this as I'm
really not sure about what's going on here. But let's see if we can do
anything about this ourselves...

DG> The erlang port hangs during initialization om mac (snow leopard),
DG> since commit (git) b0fa6efc8
DG> using #ifdef wxABORT_ON_CONFIG_ERROR not just #if as elsewhere
DG>
DG> git-svn-id:
DG> https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74656c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

FWIW the commit message is incorrect, the changes in this revision don't
have anything to do with wxABORT_ON_CONFIG_ERROR but rather change how
OnInit() is called in wxOSX, see http://trac.wxwidgets.org/changeset/74656

DG> Backtrace is:
DG>
DG> #0 0x00007fff8a605d7a in mach_msg_trap ()
DG> #1 0x00007fff8a6063ed in mach_msg ()
DG> #2 0x00007fff81bb1902 in __CFRunLoopRun ()
DG> #3 0x00007fff81bb0d8f in CFRunLoopRunSpecific ()
DG> #4 0x00007fff808da7ee in RunCurrentEventLoopInMode ()
DG> #5 0x00007fff808da5f3 in ReceiveNextEventCommon ()
DG> #6 0x00007fff808da4ac in BlockUntilNextEventMatchingListInMode ()
DG> #7 0x00007fff8877eeb2 in _DPSNextEvent ()
DG> #8 0x00007fff8877e801 in -[NSApplication
DG> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
DG> #9 0x00007fff8874468f in -[NSApplication run] ()
DG> #10 0x0000000013c9dfa8 in wxGUIEventLoop::OSXDoRun ()
DG> #11 0x0000000014438ddf in wxCFEventLoop::DoRun ()
DG> #12 0x00000000143777e1 in wxEventLoopBase::Run ()
DG> #13 0x000000001433bfa7 in wxAppConsoleBase::MainLoop ()
DG> #14 0x0000000013c30147 in wxApp::OnRun ()
DG> #15 0x00000000143b5393 in wxEntry ()
DG> #16 0x0000000013181c5b in wxe_main_loop (vpdl=0x11c823f8) at
DG> wxe_impl.cpp:237
DG> #17 0x00000000100259bb in erl_start (argc=<value temporarily unavailable,
DG> due to optimizations>, argv=0x7fff5fbfef20) at beam/erl_init.c:1775
DG>
DG> Took me a day to find that commit, on my old and slow mac mini via a manual
DG> bisect.
DG>
DG> Is it something I have change to make it work or is that bug wxWidgets?

If the previously working code now hangs, I'd say it's bug in wx. But the
trouble is that I have no idea why does it hang... Is your OnInit() called
at all? And what do you do in it that could depend on the order in which
things are done?

Regards,
VZ

[Dan Gudmundsson]

Hmm, now I'm confused, is this a snow leopard issue?

If I build and run text sample with from a terminal

text.app/Contents/MacOS/text

I get no window until I click the icon in the "toolbar" is that how it should be?

And if I start the text.app from the Finder I get a message box saying rougly:

"You can't open the application text because it may be damaged or incomplete"

As you can see I'm not used to the mac, just occasionally testing my software on it..

A workmate will bring his macbook tomorrow with a newer OS, will do more tests on that.

More comments inlined

On Wed, Sep 18, 2013 at 6:43 PM, Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Thu, 12 Sep 2013 10:51:31 +0200 Dan Gudmundsson wrote:

DG> Hi guys I have a problem with the current versions.

 Hello,

 Sorry for the lack of reply, I hoped Stefan would answer this as I'm
really not sure about what's going on here. But let's see if we can do
anything about this ourselves...

So did I :-)

Maybe I should have filed a bug report in trac directly

 

DG> The erlang port hangs during initialization om mac (snow leopard),
DG> since commit (git) b0fa6efc8
DG>     using #ifdef wxABORT_ON_CONFIG_ERROR not just #if as elsewhere
DG>
DG>     git-svn-id:
DG> https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74656c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

 FWIW the commit message is incorrect, the changes in this revision don't
have anything to do with wxABORT_ON_CONFIG_ERROR but rather change how
OnInit() is called in wxOSX, see http://trac.wxwidgets.org/changeset/74656

 

Saw that 

No, at least debug printouts doesn't show up, the last debug I can see is before entering wxEntry

 

 Regards,
VZ

[Dan Gudmundsson]

False alarm, kind of anyway.

Since I load all wx stuff from a dylib from a console app I use the "famous" hack:

   ProcessSerialNumber psn;

   // Enable GUI 

   if(!GetCurrentProcess(&psn)) {

      TransformProcessType(&psn, kProcessTransformToForegroundApplication);

      SetFrontProcess(&psn);

   }

so that I could use the gui from an console app, I called this code from inside OnInit().

If I call it before wxEntry, everything works nicely.

I guess that there are more people, that does the above, so they should be warned.

/Dan

[Václav Slavík]

Hi,

On 18 Sep 2013, at 18:43, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> FWIW the commit message is incorrect, the changes in this revision don't
> have anything to do with wxABORT_ON_CONFIG_ERROR but rather change how
> OnInit() is called in wxOSX, see http://trac.wxwidgets.org/changeset/74656

...

> If the previously working code now hangs, I'd say it's bug in wx. But the
> trouble is that I have no idea why does it hang... Is your OnInit() called
> at all? And what do you do in it that could depend on the order in which
> things are done?

It breaks Poedit too -- and every other application that expects OnInit() to be called as one of the first things, specifically before MacNewFile() or MacOpenFiles(). The above commit changed it and MacNewFile() is called before OnInit(), which I think is clearly wrong (in addition to being incompatible with 2.8).

I reverted the offending commit for now. I don't know what else to do about it, I don't understand the commit's purpose at all (and the mistaken commit message doesn't help).

Regards,
Vaclav

[Stefan Csomor]

Hi

we had different problems with the sequence of events during app startup
depending on where OnInit is called and when the event loop gets started

- a modal dialog loop in OnInit was not working
- a message box in OnInit hat no Accessibility support - ie no screen
reading possible
- a file open event apple event got lost

https://groups.google.com/forum/#!topic/wx-dev/an-xUH2CPrY

https://groups.google.com/forum/#!topic/wx-users/dnf_pRLUg6s

http://trac.wxwidgets.org/ticket/15413

http://trac.wxwidgets.org/changeset/74656 was related to the second thread
about the dialog in the OnInit Š

I'll experiment and try to find out what I can do to find a solution that
solves all issues Š

Best,

Stefan

[Vadim Zeitlin]

On Sat, 21 Sep 2013 11:55:56 +0000 Stefan Csomor wrote:

SC> we had different problems with the sequence of events during app startup
SC> depending on where OnInit is called and when the event loop gets started
SC>
SC> - a modal dialog loop in OnInit was not working
SC> - a message box in OnInit hat no Accessibility support - ie no screen
SC> reading possible
SC> - a file open event apple event got lost
SC>
SC> https://groups.google.com/forum/#!topic/wx-dev/an-xUH2CPrY
SC>
SC> https://groups.google.com/forum/#!topic/wx-users/dnf_pRLUg6s
SC>
SC> http://trac.wxwidgets.org/ticket/15413
SC>
SC> http://trac.wxwidgets.org/changeset/74656 was related to the second thread
SC> about the dialog in the OnInit Š
SC>
SC> I'll experiment and try to find out what I can do to find a solution that
SC> solves all issues Š

The trouble is that I still don't understand what was the problem with
Dan's and Vaclav's code. I.e. why did this patch (r74656) broke it exactly?
Does anybody know it? Can I somehow help you with fixing this? It looks
like a rather serious problem and I'd strongly prefer to fix it before 3.0
RC1.

TIA,
VZ

[Václav Slavík]

On 29 Sep 2013, at 15:28, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> The trouble is that I still don't understand what was the problem with
> Dan's and Vaclav's code. I.e. why did this patch (r74656) broke it exactly?
> Does anybody know it?

The patch moved OnInit() call from OSXOnWillFinishLaunching (i.e. applicationWillFinishLaunching:) to after calling [NSApp run]. Presumably that [NSApp run] call handles the initial events and calls application:openFile: and thus MacOpenFile() -- *before* OnInit() gets called.

The "problem" with my code was that I expected OnInit (which is described as "initiating application processing" and "main() equivalent" by the docs) to be called first, before any other method, including MacOpenFile().

Vaclav

[Stefan Csomor]

Hi

I'll probably have to store that event and trigger it myself afterwards,
if I don't run the event loop a first time, then things don't get inited
properly in the OS, and OnInit does not have accessibility for message
boxes etc. I'll have to try things out again Š

Thanks,

Stefan

[Vadim Zeitlin]

On Sun, 29 Sep 2013 19:18:12 +0000 Stefan Csomor wrote:

SC> >On 29 Sep 2013, at 15:28, Vadim Zeitlin <va...@wxwidgets.org> wrote:
SC> >> The trouble is that I still don't understand what was the problem with
SC> >> Dan's and Vaclav's code. I.e. why did this patch (r74656) broke it
SC> >>exactly?
SC> >> Does anybody know it?
SC> >
SC> >The patch moved OnInit() call from OSXOnWillFinishLaunching (i.e.
SC> >applicationWillFinishLaunching:) to after calling [NSApp run]. Presumably
SC> >that [NSApp run] call handles the initial events and calls
SC> >application:openFile: and thus MacOpenFile() -- before OnInit() gets
SC> >called.
SC> >
SC> >The "problem" with my code was that I expected OnInit (which is described
SC> >as "initiating application processing" and "main() equivalent" by the
SC> >docs) to be called first, before any other method, including
SC> >MacOpenFile().
SC>
SC> I'll probably have to store that event and trigger it myself afterwards,
SC> if I don't run the event loop a first time, then things don't get inited
SC> properly in the OS, and OnInit does not have accessibility for message
SC> boxes etc. I'll have to try things out again Š

The ideal sequence of events would be:

(1) Start the main loop at OS X level ([NSApp run])
(2) OnInit()
(3) OnLaunched()
(4a) MacOpenFile()
(4b) Start the main loop at wx level and call OnEventLoopEnter()

I don't think there is any expected relative order between the last two
items, which is why I put them both under (4), but (1) must be done before
(2) for the code in OnInit() to work correctly and (2) must be called
before both (4a) and (4b) because this is what the existing code expects.
Finally, (3) must be done after (2) but before anything else for
OnLaunched() to be really useful.

So the above really seems like the only possibility. If it's
implementable, great. If it isn't, I really don't see what to do however.

Regards,
VZ

[Václav Slavík]

Hi,

On 30 Sep 2013, at 00:34, Vadim Zeitlin <va...@wxwidgets.org> wrote:
> (1) Start the main loop at OS X level ([NSApp run])
> (2) OnInit()
> (3) OnLaunched()
> (4a) MacOpenFile()
> (4b) Start the main loop at wx level and call OnEventLoopEnter()
>
> I don't think there is any expected relative order between the last two
> items, which is why I put them both under (4), but (1) must be done before
> (2) for the code in OnInit() to work correctly and (2) must be called
> before both (4a) and (4b) because this is what the existing code expects.
> Finally, (3) must be done after (2) but before anything else for
> OnLaunched() to be really useful.

It's probably easier said than done, because it doesn't map well to the native notifications sent to the app delegate:

osx1. applicationWillFinishLaunching:
osx2. application:openFile: and similar (e.g. NSAppleEventManager-registered handlers) are called
osx3. applicationDidFinishLaunching:

If step 1. is too early to do OnInit (thanks for the explanation, Stefan!), because wx apps typically launch UI from there, then this is indeed tricky.

The problem is that wx apps often combine tasks that should be done in 1. (various app setup, things the wxApp ctor would be too early for) and 3. (showing initial UI). The cleanest, but not backward compatible, solution, would be to split (allow splitting) the initialization into two steps.

This OnLaunched() thing could be useful for it (if it was documented and guaranteed to be called immediately after initialization even if no window was created yet (would MSW event loop run then?)). But the sequence of events that could be implemented easily in wxOSX would then be this, rather than what you wrote above:

- OnInit()
- MacOpenFile()
- OnLaunched()

> So the above really seems like the only possibility. If it's
> implementable, great. If it isn't, I really don't see what to do however.

At the very least we could (and should in any case)

a) add appropriate virtual functions corresponding to osx1 and osx2 points in initialization,
b) document the order of calls, both in app overview and in every involved function's description,
c) in OnInit documentation, recommend overriding the new functions instead

Then we could re-apply Stefan's change and while it would break apps, it would at least be possible to update them with only little effort. And it would IMHO be better than crashing apps or broken accessibility (and who knows what else).

Regards,
Vaclav

[Stefan Csomor]

Hi Vaclav

could you please try whether r74947 works for you ? this keeps modal
dialogs working in OnInit

Thanks,

Stefan

[Václav Slavík]

On 6 Oct 2013, at 23:13, Stefan Csomor <cso...@advancedconcepts.ch> wrote:
> Hi Vaclav
>
> could you please try whether r74947 works for you ?

It does, thanks, but it is still broken for other Apple events: I tested MacOpenURL() (which is still called before OnInit now) and I expect MacPrintFile() to be similarly affected.

Regards,
Vaclav

[Vadim Zeitlin]

On Mon, 7 Oct 2013 10:22:05 +0200 Václav Slavík wrote:

VS> On 6 Oct 2013, at 23:13, Stefan Csomor <cso...@advancedconcepts.ch> wrote:
VS> > Hi Vaclav
VS> >
VS> > could you please try whether r74947 works for you ?
VS>
VS> It does, thanks, but it is still broken for other Apple events: I
VS> tested MacOpenURL() (which is still called before OnInit now) and I
VS> expect MacPrintFile() to be similarly affected.

Thanks for testing this, but I still don't know what should I do for RC1.
Should I try to (blindly) apply the same fix as in r74947 for these other
methods? I.e. also store files to be printed and URLs?

VZ

[Stefan Csomor]

Hi

I'll do that, now that I'm sure Vaclav's code works again, I'll notify

Thanks,

Stefan

[Vadim Zeitlin]

On Mon, 7 Oct 2013 10:08:34 +0000 Stefan Csomor wrote:

SC> > Thanks for testing this, but I still don't know what should I do for RC1.
SC> >Should I try to (blindly) apply the same fix as in r74947 for these other
SC> >methods? I.e. also store files to be printed and URLs?
SC>
SC> I'll do that, now that I'm sure Vaclav's code works again, I'll notify

Thanks!

BTW, I wonder if application:openFiles: can be called more than once
during startup? Because if it can be, we'd be losing the first set of files
in this case. I.e. shouldn't we append to the existing files in
OSXStoreOpenFiles instead of replacing them?

VZ

[Stefan Csomor]

Hi

thanks for testing, I'll apply the same for openURL and printFile now that
I'm sure it works again,

Thanks,

Stefan

[Stefan Csomor]

Hi

actually it should only be called once, I've also changed to a different
callback for printFile which coalesces all files into one, r74954 and
r74955 has the printFile and the getURL additions.

Best,

Stefan

[Vadim Zeitlin]

On Mon, 7 Oct 2013 11:26:04 +0000 Stefan Csomor wrote:

SC> actually it should only be called once, I've also changed to a different
SC> callback for printFile which coalesces all files into one, r74954 and
SC> r74955 has the printFile and the getURL additions.

OK, thanks, I'm making 3.0.0-rc1 archives and uploading them right now.
VZ