digitalmars.D.learn - if (X !is null && X.Y !is null) access crash
- 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
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.
Jun 07 2019
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)
Jun 07 2019
On Friday, 7 June 2019 at 14:07:34 UTC, KnightMare wrote:On Friday, 7 June 2019 at 09:26:52 UTC, Amex wrote: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.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)
Jun 07 2019
It happens when I close down my app.is this inside a destructor?
Jun 07 2019
On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote: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.It happens when I close down my app.is this inside a destructor?
Jun 07 2019
On 6/8/19 2:28 AM, Amex wrote:On Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote: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. -SteveNo, 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.It happens when I close down my app.is this inside a destructor?
Jun 08 2019
On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote:On 6/8/19 2:28 AM, Amex wrote: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 Friday, 7 June 2019 at 16:09:47 UTC, Adam D. Ruppe wrote: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. -SteveNo, 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.It happens when I close down my app.is this inside a destructor?
Jun 08 2019
On 6/9/19 1:25 AM, Amex wrote:On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote:I'm not sure if you can shut off the final collection. All you can do is disable collections during allocations. -SteveTry 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.
Jun 10 2019
On Monday, 10 June 2019 at 19:48:18 UTC, Steven Schveighoffer wrote:On 6/9/19 1:25 AM, Amex wrote: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.On Saturday, 8 June 2019 at 20:44:13 UTC, Steven Schveighoffer wrote:I'm not sure if you can shut off the final collection. All you can do is disable collections during allocations. -SteveTry 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.
Jun 10 2019