Crashing while debugging

Hi, today I ran into a tricky problem.

My Desktop App evaluates Commandline Strings for importing files “headless” before the first window is opened.
So I am checking the Commandline String in the app.Open Event and do the import stuff.
When it is done, I am quitting the App.

So far so good… but this leads into hard crashes of my app… even within debugger.

What I am missing? Is app.Open Event the right place to do this?
Is it possible that my Quit Command causes this Inconsistency?

Here’s the systems’ error log:

Process:               DataReader.debug [1674]
Path:                  /Users/USER/Documents/*/DataReader.debug.app/Contents/MacOS/DataReader.debug
Identifier:            com.jakobssystems.DataReader
Version:               1.0 (1.0.0.3.21)
Code Type:             X86 (Native)
Parent Process:        ??? [1]
Responsible:           DataReader.debug [1674]
User ID:               501

Date/Time:             2014-12-18 23:35:20.838 +0100
OS Version:            Mac OS X 10.10.1 (14B25)
Report Version:        11
Anonymous UUID:        8499CF80-6108-9289-669C-83C831F631D4

Sleep/Wake UUID:       43788E6A-4A45-489C-A974-2E476C1BEB94

Time Awake Since Boot: 23000 seconds
Time Since Wake:       19000 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000002, 0x0000000000000000

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'NSApp with wrong _running count'

Application Specific Backtrace 1:
0   CoreFoundation                      0x92e7c343 __raiseError + 195
1   libobjc.A.dylib                     0x9bf4ca2a objc_exception_throw + 276
2   CoreFoundation                      0x92e7c1ca +[NSException raise:format:arguments:] + 138
3   Foundation                          0x91ee22b1 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 118
4   AppKit                              0x96e12bb2 -[NSApplication run] + 401
5   XojoFramework                       0x006fdd77 SSLSettings_SetValidateCertificates + 1095
6   XojoFramework                       0x006fc32f RuntimeRun + 49
7   DataReader.debug                    0x0014d0e1 REALbasic._RuntimeRun + 34
8   DataReader.debug                    0x0000590a _Main + 257
9   DataReader.debug                    0x000026dc main + 36
10  DataReader.debug                    0x00517193 start + 53

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.CoreFoundation      	0x92e7ccd7 ___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 7
1   com.apple.CoreFoundation      	0x92e7c659 __raiseError + 985
2   libobjc.A.dylib               	0x9bf4ca2a objc_exception_throw + 276
3   com.apple.CoreFoundation      	0x92e7c1ca +[NSException raise:format:arguments:] + 138
4   com.apple.Foundation          	0x91ee22b1 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 118
5   com.apple.AppKit              	0x96e12bb2 -[NSApplication run] + 401
6   com.xojo.XojoFramework        	0x006fdd77 0x5a9000 + 1396087
7   com.xojo.XojoFramework        	0x006fc32f RuntimeRun + 49
8   com.jakobssystems.DataReader  	0x0014d0e1 REALbasic._RuntimeRun + 34
9   com.jakobssystems.DataReader  	0x0000590a _Main + 257
10  com.jakobssystems.DataReader  	0x000026dc main + 36
11  com.jakobssystems.DataReader  	0x00517193 start + 

....

it is defintily the Quit Line in the app.Open Event which causes the crash… how to evade this?

    if CommandLineString <> "" then
      app.Action_ImportHeadless(CommandLineString)
      Quit
    end if

[quote=153505:@Tomas Jakobs]it is defintily the Quit Line in the app.Open Event which causes the crash… how to evade this?

if CommandLineString <> "" then app.Action_ImportHeadless(CommandLineString) Quit end if [/quote]

Placing quit in the Open event in 2014R3.1 does not create a crash. Could that be your method ?

If the crash is not in the method, why not set a flag and then quit in the Open event of the first window instead ?

Because I am asking the user in CancelClose Event of Main Window if he really wants to quit.
When using a commandline no window should be opened at all.

I am thinking in making a console helper app doing this job… but I m curious this inconsitency error. Seems to look like a bug in the framework?

To go “headless”, make sure you set the Default Window to “None” and then explicitly .Show the window in app.Open as appropriate.

[quote=153510:@Tomas Jakobs]Because I am asking the user in CancelClose Event of Main Window if he really wants to quit.
When using a commandline no window should be opened at all.

I am thinking in making a console helper app doing this job… but I m curious this inconsitency error. Seems to look like a bug in the framework?[/quote]

What I say is, if quit is the only command in the open event, I see no crash. So I wonder what your method Action_ImportHeadless() does. You may want to try commenting out the the line that calls it and see if the crash still occurs.

I’ve created a project where you can reproduce this error:
dont forget to type in something into Command Line Arguments in Shared Build Settings…

https://dl.dropboxusercontent.com/u/30535865/xojo/demo.xojo_binary_project

[quote=153516:@Tomas Jakobs]I’ve created a project where you can reproduce this error:
dont forget to type in something into Command Line Arguments in Shared Build Settings…

https://dl.dropboxusercontent.com/u/30535865/xojo/demo.xojo_binary_project[/quote]

Thank you. It is not the method.

I got it. It is quite a devious bug here. When there is nothing in the command line, quit works fine in Open. But anything in the command line and it crashes. It is probably worth a bug report.

The workaround is to create a boolean flag, for instance “quitnow”, which you set with quitnow = true in open.

Then in App.Activate, you go if quitnow then quit

I verified it does not crash that way.

You could also move all your existing code into Activate ; it works just as well.

Thank you for confirmation… I will file a report right now.

@Tim: You are aware of this? Looks like a strange xojo bug in conjunction with Commandline Arguments.

feedback://showreport?report_id=37423

… and sorry for “THIS” Christmas present… :frowning:

I can’t get it to crash. Windows 7, Xojo 2014r3.1

Again, what happens if you set DefaultWindow in App properties to None? Does it still crash?

It still crashes. It must be a Mac bug only.

Yes, as MIchel pointed out, it crashes on Mac only and for your information it also crashes without any predefined Window. Norman already verified this I saw in Feedback.