MantisBT
Mantis Bug Tracker Workflow

View Revisions: Issue #2499 All Revisions ] Back to Issue ]
Summary 0002499: The assignation operator for all the maps assignation is bugged
Revision 2011-11-29 10:57 by bugmaster
Description Bug from Open CASCADE community

Autors: Joel Donneux & Ivan Fontaine

http://www.opencascade.org/forumorg/bug.php?bug_id=118&f=8 [^]

Well, a new candidate for the "Bug of Year" contest.

The assignation operator for all the maps assignation is bugged.
The destination map is resized using the number of buckets of the
map. The result of this is that during an assignation all the destination maps
are sized to the "NextPrime" size.

If you have a map with one element and if you copy it 26 times,
you end up with a map having 100019 buckets to store one element.

And if your application has some map of maps and that you use CAF,
you can potentially use hundreds of mega bytes to store a few Standard_Integer
!!

Needless to say, Cascade is rather memory hungry, and this bug makes
the situation even worst.


You should alter all your maps definitions in a way like this:

TCollection_Map& TCollection_Map::Assign(const TCollection_Map& Other)
{
if (this == &Other) return *this;
Clear();
 // **** modif
// ReSize() uses the TCollection::NextPrimeForMap() to get the next bucket size,
// so, the bucket size grows at each copy, even in the number of object
// in the map is constant !
//
// ReSize(Other.NbBuckets());
//
if (!Other.IsEmpty()) {
ReSize(Other.Extent());
// **** END modif
for (TCollection_MapIterator It(Other); It.More(); It.Next()) {
Add(It.Key());
}
}
return *this;
}


Joel Donneux & Ivan Fontaine
Revision 2006-06-29 09:15 by bugmaster
Description Bug from Open CASCADE community

Autors: Joel Donneux & Ivan Fontaine

http://www.opencascade.org/forumorg/bug.php?bug_id=118&f=8 [^]

Well, a new candidate for the "Bug of Year" contest.

The assignation operator for all the maps assignation is bugged.
The destination map is resized using the number of buckets of the
map. The result of this is that during an assignation all the destination maps
are sized to the "NextPrime" size.

If you have a map with one element and if you copy it 26 times,
you end up with a map having 100019 buckets to store one element.

And if your application has some map of maps and that you use CAF,
you can potentially use hundreds of mega bytes to store a few Standard_Integer
!!

Needless to say, Cascade is rather memory hungry, and this bug makes
the situation even worst.


You should alter all your maps definitions in a way like this:

TCollection_Map& TCollection_Map::Assign(const TCollection_Map& Other)
{
if (this == &Other) return *this;
Clear();
 // **** SAMTECH modif
// ReSize() uses the TCollection::NextPrimeForMap() to get the next bucket size,
// so, the bucket size grows at each copy, even in the number of object
// in the map is constant !
//
// ReSize(Other.NbBuckets());
//
if (!Other.IsEmpty()) {
ReSize(Other.Extent());
// **** END SAMTECH modif
for (TCollection_MapIterator It(Other); It.More(); It.Next()) {
Add(It.Key());
}
}
return *this;
}


Joel Donneux & Ivan Fontaine
SAMTECH S.A.


Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker