Re: if (X !is null && X.Y !is null) access crash
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.
Re: if (X !is null && X.Y !is null) access crash
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
Re: if (X !is null && X.Y !is null) access crash
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.
Re: if (X !is null && X.Y !is null) access crash
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
Re: if (X !is null && X.Y !is null) access crash
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.
Re: if (X !is null && X.Y !is null) access crash
It happens when I close down my app. is this inside a destructor?
Re: if (X !is null && X.Y !is null) access crash
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.
Re: if (X !is null && X.Y !is null) access crash
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)
