Crashing while debugging

General
1

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 + 

....
2

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
3

[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 ?

4

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?

5

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

6

[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.

7

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

8

[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.

9

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.

10

(https://xojo.com/issue/37423)]<https://xojo.com/issue/37423>

11

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

12

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?

13

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

14

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.