How many crash reports before you guys notice??

[Jon_Ogden]

OK. So I have been continually getting a Unhandled NilObjectException in SpawnCompiler.dylib@3148 in 2017r1. I’ve reported this crash over 14 times and not one crash report has been reviewed!

Here’s some of the reports;
<https://xojo.com/issue/47585>
<https://xojo.com/issue/47584>
<https://xojo.com/issue/47580>
<https://xojo.com/issue/47579>
and more…

Several of my 14 are private.

Basically this is very repeatable. I’m compiling in debugging in 64 bit. I run the app in the debugger in 64 bit. I stop the app (I think generally stop from within Xojo). I then make edits in the app. I search for stuff, flip between tabs, etc. I then try running again and BOOM! I get the crash. Pretty darn annoying.

Can Xojo please review these? I think we need an 2017r1.1 to fix something like this…

Here’s the output:

IDE Version : 2017 Release 1

Stack Trace:
SpawnCompiler.dylib$3148
SpawnCompiler.dylib$3164
Compiler.Build%b%o<Compiler>o<CompilationUnit>A1o<CodeUnit>o<LocalizedStrings>o<BuildSettings>
SpawnCompiler.Build%b%o<SpawnCompiler>o<CompilationUnit>A1o<CodeUnit>o<LocalizedStrings>o<BuildSettings>
DebugCompileThread.Run%%o<DebugCompileThread>
StudioMainWindow.StudioMainWindow.RunApp%b%o<StudioMainWindow.StudioMainWindow>bbi4<DebuggerUtilities.OSDebugger>
StudioMainWindow.StudioMainWindow.HandleCommand%b%o<StudioMainWindow.StudioMainWindow>o<Commands.Command>
Commands.Dispatch%%o<Commands.Command>
Commands.Dispatch%%s
StudioMainWindow.StudioMainWindow.ToolbarAction%%o<StudioMainWindow.StudioMainWindow>o<ToolItem>
StudioMainWindow.StudioMainWindow.MainToolBar_Action%%o<StudioMainWindow.StudioMainWindow>o<StudioNavBar>o<ToolItem>
Delegate.IM_Invoke%%o<StudioNavBar>o<ToolItem>
AddHandler.Stub.15%%o<ToolItem>
XojoFramework$3534
XojoFramework$2687
XojoFramework$2696
-[NSObject performSelector:withObject:]
-[NSToolbarButton sendAction:to:]
-[NSToolbarButton sendAction]
-[NSToolbarItemViewer mouseDown:]
-[NSWindow _handleMouseDownEvent:isDelayedEvent:]
-[NSWindow _reallySendEvent:isDelayedEvent:]
-[NSWindow sendEvent:]
XojoFramework$1746
-[NSApplication sendEvent:]
XojoFramework$1292
XojoFramework$1293
Delegate.Invoke%%
Application._CallFunctionWithExceptionHandling%%o<Application>p
XojoFramework$9814
XojoFramework$1292
-[NSApplication run]
XojoFramework$9816
RuntimeRun
REALbasic._RuntimeRun
_Main
main
start

[Norman_P]

13 closed as duplicates
None has enough information to do anything with (repeatable steps, full crash log, sample app, etc)

[Jon_Ogden]

Of course!

It would be helpful if the framework could include more information about exactly which object is Nil. I run into that same issue myself - I get an NOE report and don’t know what caused it.

I’m trying to figure out how to duplicate this exactly. I know it keeps happening but I’m not exactly sure of the order of everything. It is certainly an issue. I’ll keep filing the automatic reports and trying to figure out what I am doing. At least now I know they have been looked at.

[Norman_P]

Several were closed as duplicates
You should have been notified of that
There was only 1 open one marked “Needs Review”

[Jon_Ogden]

OK. That wasn’t the way it was when I posted this thread.

[Norman_P]

most ALL of those were closed as duplicates before this thread started (including the 4 you sent today - Robin marked them duplicates as 2:51 AM)
The one left open as needs review is one I just marked “Information Required”

EDIT - correct “most” to “all”

[Beatrix_Willius]

Sending duplicate reports is not very useful. I have a memory leak in Xojo that nobody except me has. 100% reproducible for me. So I simply restart Xojo and omit sending the report to Feedback.

[nicolás_canessa]

It would be helpful if the framework could include more information about exactly which object is Nil

+1 for that @Norman Palardy
Do I need to open a feedback request to get this feature implemented?

[Norman_P]

uh I never wrote that

but I think <https://xojo.com/issue/15331> is already suitable

[nicolás_canessa]

haha I know you didn’t write it … it was wrote by jon ogden. the quote was used just for reference… and to avoid writing the same

[Norman_P]

@323938:@Beatrix Willius

Sending duplicate reports is not very useful. I have a memory leak in Xojo that nobody except me has. 100% reproducible for me. So I simply restart Xojo and omit sending the report to Feedback.

If they are exactly duplicate with no additional information (crash logs steps etc) then you are right that there isn’t a lot of new value in them
Being able to reproduce errors is the first step to fixing them and there are a bunch of reports we have that we dont have the means to reproduce - yet
There’s just no way we can mark them “verified”

[Maximilian_Tyrtania]

While I understand you’d like a reproducible case there sometimes just is no way to create one. The current situation is quite inconvenient (I’m crashing 5 times a day like this). Are you guys sure you absolutely can’t for example produce more detailed crash reports?

This, combined with the issue of debugbuilds not going away make me think that XOJO 2017r2.1 is a bit out of shape.

[Greg_O_Lone]

@356672:@Maximilian Tyrtania

This, combined with the issue of debugbuilds not going away make me think that XOJO 2017r2.1 is a bit out of shape.

This was caused by 10.13, not Xojo. [quote=356672:@Maximilian Tyrtania]While I understand you’d like a reproducible case there sometimes just is no way to create one. The current situation is quite inconvenient (I’m crashing 5 times a day like this). Are you guys sure you absolutely can’t for example produce more detailed crash reports?[/quote]
Considering you’re replying to a post that was created before r2 came out, either they’re not related or the problem didn’t just start in r2.

If you are crashing 5x a day, it might be helpful to us if you ran an app like Rewind to show us the what you were doing over the last minute or so. That might show the piece of the puzzle which everyone forgets to mention.

[Beatrix_Willius]

Run, run, run - crash. Run, run, run, run - crash. 64bit. 32bit is more or less stable. But 64bit is crashy as heck. Normal thought it might be related to the memory Xojo uses. But I made a small app to monitor Xojo’s memory and it never goes over 1 GB for my main project.

[DerkJ]

@356682:@Beatrix Willius

Run, run, run - crash. Run, run, run, run - crash. 64bit. 32bit is more or less stable. But 64bit is crashy as heck. Normal thought it might be related to the memory Xojo uses. But I made a small app to monitor Xojo’s memory and it never goes over 1 GB for my main project.

Mac os sierra ide 2017r2.1 64 bit builds no problem here… (not high sierra)

[shao_sean]

Yosemite, 2017r2.1 64-bit debugs… I find that the IDE crashes if I have an exception in the debug app… Same code base I was working with in 2017r2…

[Maximilian_Tyrtania]

I don’t think a Rewind-Session would enlighten the issue a lot. I usually do just some random coding, hit command -r and then it happens.

If you are looking for pieces in the puzzle - for me the crashes occur only in projects that use htmlviewers when compiling for Mac OS. I’m interested to hear if other developers also have htmlviewers in their crashing projects. I’m on High Sierra.

[Beatrix_Willius]

@Maximilian: I’ll check your idea out. I thought that the problem was related to the size/number of classes of the project.

My development machine still is on El Capitan.

[Beatrix_Willius]

Whenever I want to make Xojo crash it doesn’t work. One of my small projects with 75 items doesn’t crash Xojo. Without or with a htmlviewer. Xojo 2017r1/High Sierra.

[Beatrix_Willius]

The large project with 450 items also doesn’t crash Xojo if I only do run/quit. Tried half a dozen times which usually was enough. It must be something to do with working in the debugger.