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

  1. 3 weeks ago

    Ivan T

    Nov 22 Pre-Release Testers

    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 :|

    Delete the DebugLogs, compile, crash

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

    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?

  2. Christian S

    Nov 22 Pre-Release Testers, Xojo Pro, XDC Speakers, Third Party Store Germany

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

  3. Ivan T

    Nov 22 Pre-Release Testers
    Edited 3 weeks ago

    @ChristianSchmitz Maybe clear caches?

    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

  4. Ivan T

    Nov 22 Pre-Release Testers

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

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

  5. Tim J

    Nov 24 Pre-Release Testers N. Phoenix, AZ

    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.

  6. Rick A

    Nov 25 Pre-Release Testers (Brazil. UTC-3:00)

    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.

  7. Michael D

    Nov 25 Pre-Release Testers, Xojo Pro

    @Ivan T XojoGUIFramework32!ControlVisibleSetter+0xb
    XojoGUIFramework32!RuntimeMassPropertySetter + 0x4b3
    XojoGUIFramework32!RuntimeCreateWindow + 0x1a1

    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?
  8. Ivan T

    Nov 25 Pre-Release Testers
    Edited 3 weeks ago

    @Michael D Are you subclassing controls?

    Yes

    @Michael D 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 :|

  9. Michael D

    Nov 25 Pre-Release Testers, Xojo Pro
    Edited 3 weeks ago

    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
      Control1.Open

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

    The way around this:

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

    Nov 25 Pre-Release Testers, Xojo Pro under THE bus

    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

  11. Norman P

    Nov 25 Pre-Release Testers, Xojo Pro under THE bus

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

    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
    https://www.great-white-software.com/blog/2019/05/28/why-shadowing-should-be-avoided/
    https://www.great-white-software.com/blog/2019/06/17/follow-up-on-why-shadowing-should-be-avoided/

  12. Ivan T

    Nov 26 Pre-Release Testers

    @Norman P There's no "secret set up code"

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

    @Norman P the override of visible

    @Norman P incorrectly shadowed visible

    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

  13. Julian S

    Nov 27 Pre-Release Testers, Xojo Pro UK
    Edited 3 weeks ago

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

  14. Thomas S

    is not verified Nov 27 Pre-Release Testers, Xojo Pro

    When debugging with the windows tools, the stack shows lots of exceptions

    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?

  15. Joost R

    Nov 27 Pre-Release Testers, Xojo Pro The Netherlands

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

  16. Ivan T

    Nov 28 Pre-Release Testers

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

    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.

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

    launching the app with a debugger, for example WinDbg.

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

    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)"

  17. 2 weeks ago

    Christoph D

    Dec 5 Pre-Release Testers, Xojo Pro
    Edited 2 weeks ago

    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.

  18. Ivan T

    Dec 5 Pre-Release Testers

    @Christoph Dnbsp;Vocht So basically cleaning up your controls with the above code is better to avoid any crashes.

    what code?

or Sign Up to reply!