Zugg Software :: View topic

SubAdmin Joined: 18 Nov 2001 Posts: 5187

I initially tested this with a longer procedure that produced a crash at a different point, but I haven't been able to replicate that crash point. I also had the final step not cause a crash in some of tests, but repeating that step soon caused a crash.

Procedure
1. Launch CMud
2. Close Sessions window (ESC)
3. Enter at the command line

Posted: Sun Nov 04, 2007 7:44 am

Confirmed.

Posted: Mon Nov 05, 2007 5:50 pm

Added to bug list. Probably effects some other #UN commands as well.

Posted: Wed Nov 14, 2007 8:51 pm

As I thought, all of the #UN... commands are effected by this problem. And this one is a real problem to fix.

The problem is that the #UNVAR command is freeing the internal record for the variable and deleting it from the database. But a thread running in the background might have it's own reference pointing to this internal record. So now suddenly the variable reference in the background thread is pointing to freed memory, causing all sorts of crashes.

This is one thing I've always hated about memory management. It would be nice if the Free routine could somehow mark the memory as freed so that you could trap this in any other access to that part of memory. But since garbage collection could re-use that memory, the background thread pointer might actually point to valid memory...it just isn't the memory used by the variable anymore.

To make matters worse, Windows can switch threads at any time. So anyplace in my code that I have something like this:

Obj := FindVar( VarName)
do something with Obj.Value

then between these two statements, Windows could switch threads and execute an #UNVAR command, which now causes the Obj pointer to be invalid. The above example would be relatively easy to protect with a critical section. But there are other cases that do stuff like "Obj.Execute" to execute an alias reference, and then later access another property of Obj. And I can't put a section around all of that, because "Execute" is something that could take a long time and call all sorts of other routines, which would deadlock the critical section.

I could implement a "deleted objects list" that would keep track of what references are no longer valid. But then I'd have to change *every* reference to the objects to something that searched this list, and this would cause a huge performance decrease.

This is very similar to a past problem we had where a setting would put a refresh message into the Windows message queue, and then the setting was removed before the message was processed. But the solution to this was to delete the refresh message from the queue when the setting was deleted. The #UNVAR case is more complicated and there aren't any Windows messages involved. It's really more of a classic case of two threads accessing the same resource, and one thread deciding to destroy the object.

What I guess I'll need to do is implement a reference counting system for these objects. Then somehow I'll mark an object as "inuse" and then unmark it when I'm done. The Free routine will check to see if the object is in use and just mark it as deleted. Then, when the object's inuse count hits zero, the object will delete itself if needed. But this is going to be very time consuming to implement since I'll have to check *every* access I make to objects that might be freed by the #UN commands. There isn't any way to implement it transparently within the current class code.