App compiled with 2019r2.1 silent crash unless...

I just downloaded 2019r2.1, open a proyect (2019r1.1) compiled and… Silent crash, the window never opens.

just for curiosity, added some System.DebugLog currentMethodName on method to see if the app reached those points, compiled, launched and… the app opens and works ok :expressionless:

Delete the DebugLogs, compile, crash

Put a single DebugLog in the App.Open compile and the app works again :expressionless:

Weird, no way to reproduce in a simple proyect yet, so, anyone with a similar experience? Any idea on why a DebugLog changes the app behavior?

Maybe clear caches?
There is a button in preferences dialog.

Thanks, I try it, cache cleared before each compilation but same behavior: Compiled App runs ok with a single DebugLog and get a silent crash without it.

Changed the System.DebugLog currentMethodName to System.DebugLog "", Same behavior.

Note: In debug, runs ok even without the DebugLog

When debugging with the windows tools, the stack shows lots of exceptions, and the stack something like this:

XojoGUIFramework32!RuntimeMassPropertySetter + 0x4b3
XojoGUIFramework32!RuntimeCreateWindow + 0x1a1

I see a very similar silent crash on launch on Linux. The same code works when compiled with r2. The failure occurs with both a compiled app and in the IDE debugger on Linux. The debugger never even connects to the app when “Run”, so there’s no way to determine where the failure is occurring.

I’ll try adding a call to System.DebugLog at the beginning of App.Open.

You should compile the app including function names and run it with a ProcDump and send a link to the mini dump in a feedback to Xojo try to investigate the crash. This seems a serious hidden issue for me.

[quote=464381:@Ivan Tellez]XojoGUIFramework32!ControlVisibleSetter+0xb
XojoGUIFramework32!RuntimeMassPropertySetter + 0x4b3
XojoGUIFramework32!RuntimeCreateWindow + 0x1a1 [/quote]

From this it appears to be crashing in the setup procedure for creating a window, specifcially when it’s setting the visibility status of a particular control. I’ve seen crashes like this when I subclassed a control and overrode the .Visible() setter, and was doing something inside the setter which assumed the window and control were initialized properly.

  • Are you subclassing controls?
  • Does any of your subclassed controls override the .Visible() method?


Also yes

But, why a single call to System.DebugLog prevent the crash?

Weird wnought, after another cache clear and a restart the problem wen away, but is kind os unsettling that the compiler had a different outputs without code changes, nor optimizations :expressionless:

This sounds like it could be random / timing related, in which case the bug is probably still there, but you aren’t seeing it at the moment.

Since you are subclassing controls and using the .Visible() method, what’s probably hapening is something like this when the window opens:

  Control1.Visible = true

.Visible = true is called before Control.Open - because the IDE has inserted secret window setup code.

The way around this:

  private property mIsSetup as boolean
  Event MyControl.Open
  end Event
  Visible(assigns visible as boolean)
     if mIsSetup = false then return // if we aren't yet Opened, then skip this

would be useful to see what the override of visible looks like in the subclassed control

the stack would indicate there’s something wrong with however thats being done

There’s no “secret set up code”
The sequence is to call the constructor
Then set the initial values for the properties as in the IDE - thats RuntimeMassPropertySetter
This sets each property and IF you have incorrectly shadowed visible you can cause issues like this

Its why I wrote about this

Of course there is it. All the things the framework does without xojo code, all the win32 stuff.

Changing the visibility of some controls is not the same as overriding or shadowing the visible property
In fact, the only place where I use this is in some custom controls (containers with regular controls not always visible inside) so, there is not a “visible” property.

Also, this exact code never crashed before, just with 2019r2.1

Did it also happen with 2019r2 ?
If you build the project does it also happen?

I never could figure out how to extract a readable stack after a hard crash on Windows.

I know this doesn’t help with the original question, but could you let me know how it is done?

@Ivan Tellez - think this one is urgent and important enough to send in the project to the XOJO dev-team (under confidentiality) for research.

[quote=464992:@JulianS]Did it also happen with 2019r2 ?
If you build the project does it also happen?[/quote]

Since 2019r2 has the bevelbutton bug, I really never compiled this proyect there. the problem ONLY happend when the proyect was built in 2019r2.1, no problems in debug.

launching the app with a debugger, for example WinDbg.

The problem is that after a couple Xojo reinstalls, cache clears and windows restarts, now works, so, a FC will be a waste of time, I can se the “Closed (Not Reproducible)”

This is not new. I have this issue too. It began wih Xojo 2019r1 - compiling with previous Xojo versions do not trigger this.

Adding the above code fixes the crashes on one of my apps too. Very probably the Xojo framework is not cleaning everything nicely when you close your app.
It’s only happing when you have a lot of controls, though.
So basically cleaning up your controls with the above code is better to avoid any crashes.

what code?