I don't understand why

if (X !is null && X.Y !is null) access crash

is crashing.

It is true that it is being used in a thread. It happens when I close down my app.

The whole point of the check is to make sure X is not null but it seems to be failing.

The debugger is showing X is not null yet X.Y is null. (Y is a delegate)

I believe this is because I'm not using shared(which causes problems with orange serdes) and the GC.

I'm not sure though.

On Friday, 7 June 2019 at 09:26:52 UTC, Amex wrote:
> if (X !is null && X.Y !is null) access crash
> is crashing.

imo this code is valid. u can write shorter
if (X && X.Y)
probably crashed in some another place (X is not objRef but something else.. some code later at same line.. dunno)

On Friday, 7 June 2019 at 14:07:34 UTC, KnightMare wrote:
> On Friday, 7 June 2019 at 09:26:52 UTC, Amex wrote:
>> if (X !is null && X.Y !is null) access crash
>> is crashing.
>
> imo this code is valid. u can write shorter
> if (X && X.Y)
> probably crashed in some another place (X is not objRef but something else.. some code later at same line.. dunno)

The debugger is telling me it is at that line.

X is an object.

In the debugger X is shown with an address yet when expanded all the members are invalid. It happens rarely so it makes it even harder to diagnose. Only thing I can think of is that it has to do with the GC. I suppose I could turn off the GC for shutting down and that might prevent such as crash.

> It happens when I close down my app.

is this inside a destructor?

On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote:
>> It happens when I close down my app.
>
> is this inside a destructor?

No, it's in an external thread(it is in a callback). All I can think of is that something is happening in between the two checks since there is no way it could happen otherwise.

On 6/8/19 2:28 AM, Amex wrote:
> On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote:
>>> It happens when I close down my app.
>>
>> is this inside a destructor?
> 
> No, it's in an external thread(it is in a callback). All I can think of is that something is happening in between the two checks since there is no way it could happen otherwise.
> 
> 
> 

Possible the GC cleaned up the object already. When this happens, you get this kind of behavior (the GC intentionally sets the vtable to null to prevent invalid access).

Try GC.addRef on the X reference, and see if it helps.

-Steve

On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote:
> On 6/8/19 2:28 AM, Amex wrote:
>> On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote:
>>>> It happens when I close down my app.
>>>
>>> is this inside a destructor?
>> 
>> No, it's in an external thread(it is in a callback). All I can think of is that something is happening in between the two checks since there is no way it could happen otherwise.
>> 
>> 
>> 
>
> Possible the GC cleaned up the object already. When this happens, you get this kind of behavior (the GC intentionally sets the vtable to null to prevent invalid access).
>
> Try GC.addRef on the X reference, and see if it helps.
>
> -Steve

This is during shutdown so I imagine simply turning off the GC should work fine? That way it prevents all cases rather than having to add a bunch of specific cases each time they crop up.

On 6/9/19 1:25 AM, Amex wrote:
> On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote:
>> Try GC.addRef on the X reference, and see if it helps.
>>
> 
> This is during shutdown so I imagine simply turning off the GC should work fine? That way it prevents all cases rather than having to add a bunch of specific cases each time they crop up.

I'm not sure if you can shut off the final collection. All you can do is disable collections during allocations.

-Steve

On Monday, 10 June 2019 at 19:48:18 UTC, Steven Schveighoffer wrote:
> On 6/9/19 1:25 AM, Amex wrote:
>> On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote:
>>> Try GC.addRef on the X reference, and see if it helps.
>>>
>> 
>> This is during shutdown so I imagine simply turning off the GC should work fine? That way it prevents all cases rather than having to add a bunch of specific cases each time they crop up.
>
> I'm not sure if you can shut off the final collection. All you can do is disable collections during allocations.
>
> -Steve

So far it seems to be working. It may prevent a collection at the right time that causes the problem... it all may be coincidence.