Problem with pointers memory allocation on the same memory area
-
Hello, We use a third party library for our grids. Each grid cell has a style, one member of which is the font:
class CLibStyle
{
[...]
CLibFont m_pFont;
[...]
};During deserialization serialization in the library methods, the font is managed as follows:
ar >> m_pFont;
For our part, we deserialize the styles line by line, column by column, then storing them in a map to use them later:
CLibStyle * pStyle = NULL;
for (int nNumRow = 0; nNumRow ++; nNumRow Serialize(ar);
mapStyle->AddTail(pStyle);
}So far it's very basic but this is where we have a big problem because it happens that this deserialization, as simple as it is, allocates pointers m_pFont on the same memory areas from one loop to another. With the same archive file, this problem does not necessarily arise depending on whether you are in Debug or in Release, or even differs from one PC to another. :~ Afterwards, we inevitably have problems even if the pointers are destroyed ... Any ideas for ensuring that pointers are not allocated on the same memory range? Thanks a lot for your help.
You appear to be confusing serialization and deserialization. The first line above
ar >> m_pFont;is deserializing from the archive into them_pFontobject. So where is the deserialize code that loads the object from the archive, and what type is m_pFont? -
Hello, I'm not sure to understand how the "serialization" works in your exemple. What is ar ?
ar >> m_pFont
m_pFont is a pointer, so in my opinion, there is no allocation here, only a pointer (ar) affected to another pointer (m_pFont). You probably have one instance of your font ( managed by your code or the library, I don't know ) referenced ( pointed ) by several m_pFont.
-
You appear to be confusing serialization and deserialization. The first line above
ar >> m_pFont;is deserializing from the archive into them_pFontobject. So where is the deserialize code that loads the object from the archive, and what type is m_pFont?You are right. I've just modified and corrected my previous post ...
-
Hello, We use a third party library for our grids. Each grid cell has a style, one member of which is the font:
class CLibStyle
{
[...]
CLibFont m_pFont;
[...]
};During deserialization serialization in the library methods, the font is managed as follows:
ar >> m_pFont;
For our part, we deserialize the styles line by line, column by column, then storing them in a map to use them later:
CLibStyle * pStyle = NULL;
for (int nNumRow = 0; nNumRow ++; nNumRow Serialize(ar);
mapStyle->AddTail(pStyle);
}So far it's very basic but this is where we have a big problem because it happens that this deserialization, as simple as it is, allocates pointers m_pFont on the same memory areas from one loop to another. With the same archive file, this problem does not necessarily arise depending on whether you are in Debug or in Release, or even differs from one PC to another. :~ Afterwards, we inevitably have problems even if the pointers are destroyed ... Any ideas for ensuring that pointers are not allocated on the same memory range? Thanks a lot for your help.
Well, in fact, I've two cases : if I serialize with the following way, I've got some CLibStyle::m_pFont on the same memory during the serialization :
CLibStyle Style;
for (int nNumRow = 0; nNumRow ++; nNumRow GetStyleRowCol( nRow, nCol, Style);
Style.Serialize(ar);
}if I serialize with this second way, I've got problem during deserialization in the ar >> m_pFont line : CArchive::ReadObject can't find the corresponding runtime class ...
CLibStyle *pStyle;
for (int nNumRow = 0; nNumRow ++; nNumRow GetStyleRowCol( nRow, nCol, *pStyle);
pStyle->Serialize(ar);
} -
Well, in fact, I've two cases : if I serialize with the following way, I've got some CLibStyle::m_pFont on the same memory during the serialization :
CLibStyle Style;
for (int nNumRow = 0; nNumRow ++; nNumRow GetStyleRowCol( nRow, nCol, Style);
Style.Serialize(ar);
}if I serialize with this second way, I've got problem during deserialization in the ar >> m_pFont line : CArchive::ReadObject can't find the corresponding runtime class ...
CLibStyle *pStyle;
for (int nNumRow = 0; nNumRow ++; nNumRow GetStyleRowCol( nRow, nCol, *pStyle);
pStyle->Serialize(ar);
}Well your code remains unclear. However, if
m_pFontis a pointer, then you are going to have problems unless you also serialize the object that it is pointing at. Deserializing a pointer without the underlying object means that it will be pointing to some random portion of memory. -
Well your code remains unclear. However, if
m_pFontis a pointer, then you are going to have problems unless you also serialize the object that it is pointing at. Deserializing a pointer without the underlying object means that it will be pointing to some random portion of memory.This point is treated by the MFC CArchive::ReadObject and CArchive::WriteObject methods which are automatically called by the >> or << operator. They are able to detecte or serialize the associated RuntimeClass.
-
This point is treated by the MFC CArchive::ReadObject and CArchive::WriteObject methods which are automatically called by the >> or << operator. They are able to detecte or serialize the associated RuntimeClass.
Well if that is working then you need to use your debugger to find out what is going wrong. Also it is still not clear exactly what is wrong when you have deserialized from the archive. The comments at Storing and Loading CObjects via an Archive | Microsoft Docs[^] seem to imply that you may need to use the Serialize function rather than the insertion/extraction operators.
-
Hello, We use a third party library for our grids. Each grid cell has a style, one member of which is the font:
class CLibStyle
{
[...]
CLibFont m_pFont;
[...]
};During deserialization serialization in the library methods, the font is managed as follows:
ar >> m_pFont;
For our part, we deserialize the styles line by line, column by column, then storing them in a map to use them later:
CLibStyle * pStyle = NULL;
for (int nNumRow = 0; nNumRow ++; nNumRow Serialize(ar);
mapStyle->AddTail(pStyle);
}So far it's very basic but this is where we have a big problem because it happens that this deserialization, as simple as it is, allocates pointers m_pFont on the same memory areas from one loop to another. With the same archive file, this problem does not necessarily arise depending on whether you are in Debug or in Release, or even differs from one PC to another. :~ Afterwards, we inevitably have problems even if the pointers are destroyed ... Any ideas for ensuring that pointers are not allocated on the same memory range? Thanks a lot for your help.
The most obvious flaw I can see is that your are interverting loop test and variable increment in your
forloops. The syntax isfor (init; condition; increment)
, and you are using
for (init; increment; condition)
instead.
"Five fruits and vegetables a day? What a joke! Personally, after the third watermelon, I'm full."
-
The most obvious flaw I can see is that your are interverting loop test and variable increment in your
forloops. The syntax isfor (init; condition; increment)
, and you are using
for (init; increment; condition)
instead.
"Five fruits and vegetables a day? What a joke! Personally, after the third watermelon, I'm full."
-
Well spotted, but I would expect his app to crash if that is in the actual running system.
Yes, very well spotted ... I wrote the sample code too quickly ;)
-
Yes, very well spotted ... I wrote the sample code too quickly ;)
I also wonder why these loops are needed, since you do not even use nNumRow and nNumCol in the loops. What is the relation of the loop variables
nNumRowandnNumColto thearvariable?"Five fruits and vegetables a day? What a joke! Personally, after the third watermelon, I'm full."
-
Yes, very well spotted ... I wrote the sample code too quickly ;)
-
Well if that is working then you need to use your debugger to find out what is going wrong. Also it is still not clear exactly what is wrong when you have deserialized from the archive. The comments at Storing and Loading CObjects via an Archive | Microsoft Docs[^] seem to imply that you may need to use the Serialize function rather than the insertion/extraction operators.
Thanks for this interesting link. This one is also interesting : TN002: Persistent Object Data Format | Microsoft Docs
-
Hello, We use a third party library for our grids. Each grid cell has a style, one member of which is the font:
class CLibStyle
{
[...]
CLibFont m_pFont;
[...]
};During deserialization serialization in the library methods, the font is managed as follows:
ar >> m_pFont;
For our part, we deserialize the styles line by line, column by column, then storing them in a map to use them later:
CLibStyle * pStyle = NULL;
for (int nNumRow = 0; nNumRow ++; nNumRow Serialize(ar);
mapStyle->AddTail(pStyle);
}So far it's very basic but this is where we have a big problem because it happens that this deserialization, as simple as it is, allocates pointers m_pFont on the same memory areas from one loop to another. With the same archive file, this problem does not necessarily arise depending on whether you are in Debug or in Release, or even differs from one PC to another. :~ Afterwards, we inevitably have problems even if the pointers are destroyed ... Any ideas for ensuring that pointers are not allocated on the same memory range? Thanks a lot for your help.
Thank you all for your help. The example code is very close to the actual code and the problem is that sometimes, depending on the computer, because of the operator >> to deserialize the style m_pFont, several m_pFont pointed to the same memory area. I studied the problem with a minimal grid ... and finally realized that in my application I was not using this m_pFont. I modified my code so that I would no longer use it at all, destroy it and set it to NULL which definitively resolved my problem. If I don't fully explain the phenomenon, I think it comes from the fact that these m_pFont contained the same data and that the operators << consider the pointer had already been serialized as explained in the TN002: Persistent Object Data Format | Microsoft Docs ... Maybe ... Regards