How the heck is SELF nil ?

Class A holds a reference to an instance of Class B in property mReference (mReference as ClassB)
This reference is NOT nil
But then in one method on ClassA I do

        mReference.CallMethod( param1, param2 )

And yet when I step INTO this method and look at SELF - its nil ???
As you might guess this causes no end of issues
I have added a desrtuctor to ClassB - never gets called
mReference isn’t a weakRef so its not going nil on me that I can find

yet there it is - self is nil IN a method on the instance that is being run

Anyone got ANY wild assed guesses how to even track this down ?

can’t reproduce in xojo 2019r3.1
i not step into, i just set a breakpoint in CallMethod and self was there in debug window.

yeah - I dont expect a trivial example will show it but thanks anyways
I’m doing this on windows
The same code on macOS is fine but on Window I have a nil self
I’ve never seen such a behaviour in 20+ years of using Xojo before but the app crashes with a nil object exception because of this
not fun

Class A and B is a simple class or subclass?
and a breakpoint at mReference.CallMethod the debugger show mReference <> nil ?

ClassA is one class
ClassB is a differetn class
Not super / sub class at all
breakpoint before the method shows the instance of lassA’s property has a valid reference
step into the method and self is immediately shown as nil

I’ve never seen this and REALLY wish a Xojo engineer who might know WTF is goin on would shime in

@William Yu ?

and what if you create a new method for test
mReference.CallMethod2()
or
mReference2 as ClassDummy

or a strange behavior between Self. and Me.

Would it be possible to provide @William Yu a binary project file which reproduces this behavior ?
This hits the credibility of the entire working environment.

I suppose if I got a reply saying this was a possibility I would
I cant really file a bug report because I have no way to reproduce this but I can watch it in the debugger
I’ve even put in code like

      if self is nil then
            System.debuglog currentmethodname + " self is NIL !"
     end if

and compiled a binary and run that
When I run it this message shows so something screwy is going on

I’ve hunted down everything I can think of but I cannot find any destructors or events or threads or timers that are altering the property (I’ve converted it to a computed as well JUST in case)
nothing ever seems to touch this yet - self is nil when I get INTO the method that is being called IN the instance that supposedly is now nil

and then everything goes all to hell because I try to pass self on to other things that need it but - its nil - and so the app crashes

seems a LOT like the bug bob posted about
https://www.bkeeneybriefs.com/2018/11/a-xojo-existential-crisis-when-self-is-nil/

private feedback bug # 53967
seems like its still not fixed :frowning:

I have the very same application for Mac and Windows. Under Mac, even Catalina, Check Writer bug reports are exceptional.

Under Windows, I don’t count the many, many places where I had to deal with unexpected nil. The app is now full of Try-Catch, just to mitigate the Windows issues.

A shot in the dark…

As an experiment, assign the reference to class B to a global variable just before you call the method. Maybe Windows memory management sees the reference as not used and thus garbage collected.

afaict its the same bug bob described which seems to just whack memory with however the params are being passed :frowning:

What is signature of the method showing this?
e.g. is it one structure passed and some other parameter?

passing of structures by ref on windows 64 bit :frowning:
at least bob got a work around I’ll try

Bugs like this can waste a LOT of our time… This is exactly the type of bug that should be fixed as a high priority IMO, because something very basic in the language/compiler itself is wrong (vs a framework method) , regardless of of how rare they THINK it might be… It being platform specific makes it even worst.

-karen

it IS a nasty bug and a total waste of time on my part
no idea how long bob spent tracking it down

would love to see it fixed as who knows when else this might be run into

I spoke of these issues in May 2018 and warned people not to rely on xojo windows 64bit, but everyone ignored me and claimed everything was fine. <https://xojo.com/issue/52211>, still there 1.5 years later.

I’ve also recently found that byref isnt added to parameters pointing to structures when using delegates in 32bit which caused me countless hours of wasted time the other day <https://xojo.com/issue/59656> (I’ll make this public when the code is released)

¯\(?)
geoff tells me they have the people and skill sets they need to fix these
Great ! Please do

Compiler bugs like these, when you hit one, is a showstopper
I lucked out and was pointed to Bobs blog that happened to be the very same issue so I could move past it after modifying code
But if not it could have been the end of moving a product to Windows because the functionality that would be broken is so basic

Yeah, this was a ‘fun’ one to figure out. Compiler bugs really stink.

If XojoUser = "@Norman Palardy " then
Self = Nil
For each Self As Self in Selfs
   Self = Nil
Next
End If 

It seems the bug is by design