[Vortex] vortex_connection_is_ok() bug?

[Chris Yourch]

Thanks, I'm aware of the pitfalls of the various workaround methods I suggested.

I did find the problem. My "connection closed" callback was not being invoked and this was causing the problem I was having. My code removes a cached connection when the connection is closed via the connection closed callback but if the callback is not invoked then the connection stays in the cache.

Ultimately, the problem was that I did not think to call vortex_connection_set_on_close_full() on the connections that I had added to my connection cache via the listeners on-connection-accepted callback.

Chris


-----Original Message-----
From: Jens Alfke [mailto:jens at mooseyard.com]
Sent: Thursday, May 22, 2008 4:25 PM
To: Chris Yourch
Cc: Vortex
Subject: Re: [Vortex] vortex_connection_is_ok() bug?


On 22 May '08, at 1:37 PM, Chris Yourch wrote:

> Vortex obviously knows the connection has died because the memory
> for theVortexConnection object has been freed when I call
> vortex_connection_is_ok() with it. So, how about adding a check for
> the validity of the memory block that theVortexConnection object is
> using within vortex_connection_is_ok()?  Or, add a new API function
> that checks the objects validity. Something like
> vortex_connection_is_object_valid() or
> vortex_connection_is_memory_valid()?

I don't know of any API that does that! In all cases, if you pass
unallocated or freed memory to a call, the results are "undefined",
i.e. bad data or a crash. You're expected to track data structures
well enough that you don't keep your own pointers to them after
they're freed.

Since Vortex objects use ref-counting, it suffices for you to acquire
a reference to the object, and hang onto it till you're done with it.
That way the object will remain in memory, even if the connection is
closed, and vortex_connection_is_ok will work.

> For checking the validity I would suggest adding a magic number to
> each instance of an object when constructed and resetting it to 0
> when destructing it. To check the object, compare the object
> instances magic number to the actual magic number.

That won't work if the entire VM segment the block was on has been
released. In that case reading that memory will cause a bus error. The
only workaround is to set up a signal handler (or whatever the
equivalent on Windows is), but that gets tricky since it has to be
added and removed dynamically. It's just not practical to do this.

Even if that doesn't happen, the memory allocator might re-use that
block for a different instance of the same class, which would then set
the same magic number ... so this check would pass even though the
object you were asking about doesn't exist any more.

-Jens