Prev: Reference to void
Next: The D Programming Language
From: Sideswipe on 16 Nov 2006 12:57
I am running bounds checker on my dll and it keeps telling me that a
new operator I am executing is
"Overrun Detected During Execution: In block 0x0A696010 (720) allocated
by global_operator_new."

How on earth does new overwrite memory? I don't ever supply the new
operator with memory to step on!

Here is the code:
// static function
Token* Token::getInstance(Slot* slot) {
printf("%s\n",__FUNCTION__);
Token* me = NULL;
map<Slot*,Token*>::iterator itr = tokens.find(slot);

if(itr != tokens.end())
me = itr->second;
else {
me = new Token(slot);
tokens[slot] = me;
}

return me;
}

Christian
http://christian.bongiorno.org


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Thomas Maeder on 16 Nov 2006 21:02
"Sideswipe" <christian.bongiorno(a)gmail.com> writes:

> I am running bounds checker on my dll and it keeps telling me that a
> new operator I am executing is
> "Overrun Detected During Execution: In block 0x0A696010 (720) allocated
> by global_operator_new."
>
> How on earth does new overwrite memory?

I think that you are misreading this message.

I read it as:
- you are overrunning a block of memory
- that block was allocated by global_operator_new

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: stupidalias on 17 Nov 2006 14:02
On Nov 17, 2:02 am, Thomas Maeder <mae...(a)glue.ch> wrote:

> I read it as:
> - you are overrunning a block of memory
> - that block was allocated by global_operator_new

I agree,

As a point of interest, I could quite believe that some implimentations
could generated a message of "operator new has overrun some memory".
It is entirely undefined how new actually operates. If is collecting a
list of used blocks (for instance) and there has been some memory
curruption and new wants to add a new pointer to its list, it could
well end up trying to use someone elses memory and hence generate that
message. Admittedly that's quite a few "ands" but it *could* happen.

I would take any such message to actually mean "You have overwritten
some memory you were not meant to and now the fan is rather dirty, time
to start using electric fence"


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: terry on 19 Nov 2006 18:04
Dear Christian

>>>How on earth does new overwrite memory? I don't ever supply the new
>>>operator with memory to step on!
>>>
>>>Here is the code:
>>>// static function
>>>Token* Token::getInstance(Slot* slot) {
>>> printf("%s\n",__FUNCTION__);
>>> Token* me = NULL;
>>> map<Slot*,Token*>::iterator itr = tokens.find(slot);
>>>
>>> if(itr != tokens.end())
>>> me = itr->second;
>>> else {
>>> me = new Token(slot);
>>> tokens[slot] = me;
>>> }
>>>
>>> return me;
>>>}
>>>

Looking at your code - which I do not flaw - I have two (?useless) thoughts.

I wondered if I could ask why you did not let the map class manage the
memory allocation for the Tokens and removed a layer of indirection. I would
have written

map<Slot*,Token>::iterator itr = tokens.find(slot);
if(itr != tokens.end())
{
return & itr->second;
}
else
{
return & (tokens[slot] = slot);
};

Perhaps my code, through the implicit

slot -> Token(slot)
and copy into tokens[slot]

would result in an unneccesary construction destruction pair when compared
with yours; although I might hope that the compiler is clever enough to
build the temporary variable in the correct place.

I know another good reason not to embed the tokens in the map class. They
will all get destroyed when the instance of the class containing the map
class "tokens" goes out of scope. Often this is a very good thing, but there
are times when this is really not what you want. Some of the "new" objects
may need to have a persistence across compilation units.

If this second reason is close to your reason then, as you mention dlls, you
are in a context similar to one where I experienced things going wrong with
new and delete.

new or delete 'ing a Token calls the allocator or deallocator linked to the
compilation unit where the new or delete happened. The beginning and end of
the instance can be in different units. In my case, the runtime libraries
etc. linked into the code were not consistent across these different
modules. This lead to inconsistency between the allocator used in the new
and the destructor used in the delete and caused a real mess.

Doubt if anything I have said is useful for your problem and I am sure the
penultimate paragraph is obvious to you. Best regards anyhow.

Terry



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Reference to void
Next: The D Programming Language