• Amex (12/12) Jun 07 2019 I don't understand why
• KnightMare (5/7) Jun 07 2019 imo this code is valid. u can write shorter
• Amex (8/15) Jun 07 2019 The debugger is telling me it is at that line.
• Adam D. Ruppe (1/2) Jun 07 2019 is this inside a destructor?
• Amex (4/6) Jun 07 2019 No, it's in an external thread(it is in a callback). All I can
• Steven Schveighoffer (6/17) Jun 08 2019 Possible the GC cleaned up the object already. When this happens, you
• Amex (5/22) Jun 08 2019 This is during shutdown so I imagine simply turning off the GC
• Steven Schveighoffer (4/11) Jun 10 2019 I'm not sure if you can shut off the final collection. All you can do is...
• Amex (4/16) Jun 10 2019 So far it seems to be working. It may prevent a collection at the

Amex <Amex gmail.com> writes:

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.

KnightMare <black80 bk.ru> writes:

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)

Amex <Amex gmail.com> writes:

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.

Adam D. Ruppe <destructionator gmail.com> writes:

 It happens when I close down my app.

is this inside a destructor?

Amex <Amex gmail.com> writes:

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.

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Amex <Amex gmail.com> writes:

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.

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Amex <Amex gmail.com> writes:

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.