From: Tom Breton (Tehom) <tehom@pa...> - 2012-01-23 17:49:18
I noticed on the bugs list that Ted Felix found and fixed a nasty bug with
Segment being dereferenced after it's deleted (Ironically, as a debugging
help). Good work, Ted.
The fix is surrounded by stern warnings not to dereference the dead
pointer, because unavoidably, it's still there. But it actually might be
avoidable. Segment is now a QObject, so it emits the signal "destroyed"
just before it is destroyed. You could connect that signal to
CompositionMapper and do CompositionMapper::removeSegment before the
segment is actually freed, if you think it's worth doing.
I'm working on another branch right now, with some edits in
CompositionMapper that eventually I'll have to merge with this. If you
(Ted) could let me know what you end up deciding, I'd appreciate it.
Thanks for the fix.
Tom Breton (Tehom)
> But it actually might be avoidable. Segment is now a QObject, so it
emits the signal "destroyed" just before it is destroyed. You could
connect that signal to CompositionMapper and do
CompositionMapper::removeSegment before the segment is actually freed,
if you think it's worth doing.
I was just in there to fix the problem in the simplest way possible,
so I'm not familiar enough with that area to make a good decision. I'm
swamped working mainly on TrackButtons right now. So, whatever you want
to do is fine with me. I'm not planning on making any further changes
in that area.
On a somewhat related note...
One thing that crossed my mind as I was fixing that crash was that
using pointers for keys in a container can be a serious problem. It
just happens that the exact situation might exist in rg right now in
that particular area (this is what made me think of it). Here are the
steps that might lead to trouble:
1. new a pointer p1.
2. Use p1 as the key for an entry in a map.
3. delete p1, but do not delete the entry from the map just yet (it
will be cleaned up later).
4. new a pointer p2. (gets the same address that p1 had)
5. Add it to the map. (Can't. It's already there.)
At step 4, there is a possibility that the memory manager will reuse
the address that was used for p1. In fact, it's very likely with a good
Anyway, I'm not sure this is a real problem, but it certainly makes
me think twice about ever using a pointer value as a key into a map. I
usually use a serial ID, so I've never encountered this. As I was
looking at the code, I was thinking that some serious changes might be
needed (using an ID instead of an address). And that's too big of a
project for me right now.
Your solution sounds like it might lead to a direct removal from the
map. That would avoid the above problem.