Datatype Misalignment Exception
-
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.
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
-
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 ofrefCount_isUINT, and I couldn't immediately realize what harm--might do to aUINT. 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
-
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 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
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.
-
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
-
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 ofrefCount_isUINT, and I couldn't immediately realize what harm--might do to aUINT. 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
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
-
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++ :->)
See my clue at the next-to-top level.
-- Time you enjoy wasting is not wasted time - Bertrand Russel
-
See my clue at the next-to-top level.
-- Time you enjoy wasting is not wasted time - Bertrand Russel
-
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 ofrefCount_isUINT, and I couldn't immediately realize what harm--might do to aUINT. 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
That line actually means
--(this->refCount_)so thethispointer 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?
-
That line actually means
--(this->refCount_)so thethispointer 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?
Michael Dunn wrote:
the this pointer is misaligned or garbage
Tadaaa! Actually - both! ;) The
SomeSharedResourcepointer was never initialized in this particular scenario, so when checked for non-NULLness before callingSomeResource::Release, it's value was0x3b3b3b3b, which is not only non-NULLbut also clearly an unaligned pointer value. So the actual problem was not really thatrefCount_was unaligned in some way, but the fact thatthiswas 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