Datatype Misalignment Exception

Johann Gerell

I got into some trouble when some object I was using released one of its shared resources of type SomeSharedResource* in its destructor. The line --refCount_ below caused a datatype misalignment system exception. The type of refCount_ is UINT, and I couldn't immediately realize what harm -- might do to a UINT. However, finding a repro and examining the call stack before --refCount_ got executed revealed the cause of the problem. Can you guess what it was?

void SomeSharedResource::Release()
{
--refCount_;
.
.
.
}

As always, the first correct answer wins a pink toaster.

-- Time you enjoy wasting is not wasted time - Bertrand Russel

Pete OHanlon

Was refCount a pointer by any chance? If so, decrementing it would cause it to move out of alignment.

Deja View - the feeling that you've seen this post before.

Johann Gerell

Pete O`Hanlon wrote:

Was refCount a pointer by any chance?

Nope, a plain UINT, as stated.

Pete O`Hanlon wrote:

If so, decrementing it would cause it to move out of alignment

If it was a pointer, I think the problem would only occur if it was declared as a pointer to something of incompatible size, say a BYTE or WORD, then decremented and after that cast to UINT* and dereferenced.

-- Time you enjoy wasting is not wasted time - Bertrand Russel

Ed Poore

Was refCount_ set to 0 before the desctructor being called? Just a guess :~

Johann Gerell

Nope, but this is not the problem. The new value was actually validated after the decrement (in the dotted lines...). Clue: If the value of refCount_ had been validated before instead of after the decrement, the misalignment cause might have been caught quicker.

-- Time you enjoy wasting is not wasted time - Bertrand Russel

Pete OHanlon

Johann Gerell wrote:

If it was a pointer, I think the problem would only occur if it was declared as a pointer to something of incompatible size, say a BYTE or WORD, then decremented and after that cast to UINT* and dereferenced.

Of course it would. I've been out of C too long it seems.:-O Time for me to brush up on my pointers again.

Deja View - the feeling that you've seen this post before.

Ed Poore

Ok since it could be any number of values I'm going to hazard a guess that it was 1 going into the destructor and thus any code later on used a refCount of 0? (I'm not a C++ programmer so may miss any subtle bugs specific to C++ :->)

Johann Gerell

Johann Gerell wrote:

I got into some trouble when some object I was using released one of its shared resources of type SomeSharedResource* in its destructor.

-- Time you enjoy wasting is not wasted time - Bertrand Russel

Johann Gerell

See my clue at the next-to-top level.

-- Time you enjoy wasting is not wasted time - Bertrand Russel

Ed Poore

Probably something to do with the fact that it's a pointer? (Not the refCount_). Can't be more specific sorry :-O

Michael Dunn

That line actually means --(this->refCount_) so the this pointer is misaligned or garbage.

--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ Ford, what's this fish doing in my ear?

Johann Gerell

Michael Dunn wrote:

the this pointer is misaligned or garbage

Tadaaa! Actually - both! ;) The SomeSharedResource pointer was never initialized in this particular scenario, so when checked for non-NULLness before calling SomeResource::Release, it's value was 0x3b3b3b3b, which is not only non-NULL but also clearly an unaligned pointer value. So the actual problem was not really that refCount_ was unaligned in some way, but the fact that this was unaligned. Had it been aligned, but unitialized, this problem would have been harder to find, since that likely just would have resulted in garbage and maybe later trashed data.

-- Time you enjoy wasting is not wasted time - Bertrand Russel