In article <rs80oihm7r30@corp.supernews.com>, "Steven S. Wolf"
<steve.nospam@crocker.com> wrote:

> I have an application which was working (no memory leeks, did right thing,
> etc.).
>
> Then I merged in some changes from another developer which altered a class
> Foo which is stored in some maps:
>
>     typedef std::map<int, Foo> map_int_foo;
>
> Now, deep in my code, I issue the following:
>
>     map_int_foo fooMap;
>     ...
>
>     // return true if our map of Foos contains the key nKey:
>     map_int_foo::iterator it = fooMap.find(nKey);                        //
> <- THIS LINE THROWS

What kind of exception?

>     if (it == fooMap.end())
>         return false;
>     return true;
>
> Using VC++ 6.0 SP3 (with all of the fixes & patches at Dinkumware applied),
> I get a memory access violation in nodeptr when it is looking up _Root() in
> _Nodeptr const_iterator::_Lbound( ) const, which is executed as part of the
> find() method call above.

Wait, I thought you said it threw an exception. If it gets some sort of
internal error (access violation, assertion failure), then it is likely a
bug and thus has no place here on comp.std.c++. Oh, right, M$ throws
exceptions when the state of the process was corrupted. Gotta keep this in
mind.

[snip]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I have an application which was working (no memory leeks, did right thing,
etc.).

Then I merged in some changes from another developer which altered a class
Foo which is stored in some maps:

    typedef std::map<int, Foo> map_int_foo;

Now, deep in my code, I issue the following:

    map_int_foo fooMap;
    ...

    // return true if our map of Foos contains the key nKey:
    map_int_foo::iterator it = fooMap.find(nKey);                        //
<- THIS LINE THROWS
    if (it == fooMap.end())
        return false;
    return true;

Using VC++ 6.0 SP3 (with all of the fixes & patches at Dinkumware applied),
I get a memory access violation in nodeptr when it is looking up _Root() in
_Nodeptr const_iterator::_Lbound( ) const, which is executed as part of the
find() method call above.

I am having a hellish time fathoming what about Foo could possibly have
changed which would impact map_int_foo in such a way as to cause memory
access violations during a find() operation?

Any ideas would be most welcome!  At this point, I'm having to consider
using MFC's map classes in order to have code which works - or at least
sheds some light on what the !#$! is happening?

Here's the stack dump:
std::_Tree<unsigned int,std::pair<unsigned int const
,CDynamicMenuItemWrapper>,std::map<unsigned
int,CDynamicMenuItemWrapper,std::less<unsigned
int>,std::allocator<CDynamicMenuItemWrapper> >::_Kfn,std::less<unsigned
int>,std::allocator<CDynamicMen64dd5362(const unsigned int & 500) line 514 +
20 bytes
std::_Tree<unsigned int,std::pair<unsigned int const
,CDynamicMenuItemWrapper>,std::map<unsigned
int,CDynamicMenuItemWrapper,std::less<unsigned
int>,std::allocator<CDynamicMenuItemWrapper> >::_Kfn,std::less<unsigned
int>,std::allocator<CDynamicMene6f68eea(const unsigned int & 500) line 409 +
24 bytes
std::_Tree<unsigned int,std::pair<unsigned int const
,CDynamicMenuItemWrapper>,std::map<unsigned
int,CDynamicMenuItemWrapper,std::less<unsigned
int>,std::allocator<CDynamicMenuItemWrapper> >::_Kfn,std::less<unsigned
int>,std::allocator<CDynamicMend5f55b54(const unsigned int & 500) line 394 +
28 bytes
std::map<unsigned int,CDynamicMenuItemWrapper,std::less<unsigned
int>,std::allocator<CDynamicMenuItemWrapper> >::find(const unsigned int &
500) line 121 + 28 bytes

To be certain, examining the stack doesn't show anything to be null.  At
least not that I've found...

--

Steven S. Wolf
Senior Software Architect
steveATcrockerDOTcom

"Today's commercial software projects are among the most complex engineering
undertakings of humankind."
- Bartosz Milewski  (www.relisoft.com)

"...well over half of the time you spend working on a project (on the order
of 70 percent) is spent thinking, and no tool, no matter how advanced, can
think for you. Consequently, even if a tool did everything except the
thinking for you -- if it wrote 100 percent of the code, wrote 100 percent
of the documentation, did 100 percent of the testing, burned the CD-ROMs,
put them in boxes, and mailed them to your customers -- the best you could
hope for would be a 30 percent improvement in productivity. In order to do
better than that, you have to change the way you think. "
- Fred Brook [paraphrased] [as quoted from Allen Holub's
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Does Foo have the copy constructor and operator= overloaded?

Steven S. Wolf <steve.nospam@crocker.com> wrote in message
news:rs80oihm7r30@corp.supernews.com...
| I have an application which was working (no memory leeks, did
right thing,
| etc.).
|
| Then I merged in some changes from another developer which
altered a class
| Foo which is stored in some maps:
|
|     typedef std::map<int, Foo> map_int_foo;
|
| Now, deep in my code, I issue the following:
|
|     map_int_foo fooMap;
|     ...
|
|     // return true if our map of Foos contains the key nKey:
|     map_int_foo::iterator it = fooMap.find(nKey);
//
| <- THIS LINE THROWS
|     if (it == fooMap.end())
|         return false;
|     return true;
|
| Using VC++ 6.0 SP3 (with all of the fixes & patches at
Dinkumware applied),
| I get a memory access violation in nodeptr when it is looking
up _Root() in
| _Nodeptr const_iterator::_Lbound( ) const, which is executed as
part of the
| find() method call above.
|
| I am having a hellish time fathoming what about Foo could
possibly have
| changed which would impact map_int_foo in such a way as to
cause memory
| access violations during a find() operation?
|
| Any ideas would be most welcome!  At this point, I'm having to
consider
| using MFC's map classes in order to have code which works - or
at least
| sheds some light on what the !#$! is happening?
|
| Here's the stack dump:
| std::_Tree<unsigned int,std::pair<unsigned int const
| ,CDynamicMenuItemWrapper>,std::map<unsigned
| int,CDynamicMenuItemWrapper,std::less<unsigned
| int>,std::allocator<CDynamicMenuItemWrapper>
>::_Kfn,std::less<unsigned
| int>,std::allocator<CDynamicMen64dd5362(const unsigned int &
500) line 514 +
| 20 bytes
| std::_Tree<unsigned int,std::pair<unsigned int const
| ,CDynamicMenuItemWrapper>,std::map<unsigned
| int,CDynamicMenuItemWrapper,std::less<unsigned
| int>,std::allocator<CDynamicMenuItemWrapper>
>::_Kfn,std::less<unsigned
| int>,std::allocator<CDynamicMene6f68eea(const unsigned int &
500) line 409 +
| 24 bytes
| std::_Tree<unsigned int,std::pair<unsigned int const
| ,CDynamicMenuItemWrapper>,std::map<unsigned
| int,CDynamicMenuItemWrapper,std::less<unsigned
| int>,std::allocator<CDynamicMenuItemWrapper>
>::_Kfn,std::less<unsigned
| int>,std::allocator<CDynamicMend5f55b54(const unsigned int &
500) line 394 +
| 28 bytes
| std::map<unsigned
int,CDynamicMenuItemWrapper,std::less<unsigned
| int>,std::allocator<CDynamicMenuItemWrapper> >::find(const
unsigned int &
| 500) line 121 + 28 bytes
|
| To be certain, examining the stack doesn't show anything to be
null.  At
| least not that I've found...
|
| --
|
| Steven S. Wolf
| Senior Software Architect
| steveATcrockerDOTcom
|
| "Today's commercial software projects are among the most
complex engineering
| undertakings of humankind."
| - Bartosz Milewski  (www.relisoft.com)
|
| "...well over half of the time you spend working on a project
(on the order
| of 70 percent) is spent thinking, and no tool, no matter how
advanced, can
| think for you. Consequently, even if a tool did everything
except the
| thinking for you -- if it wrote 100 percent of the code, wrote
100 percent
| of the documentation, did 100 percent of the testing, burned
the CD-ROMs,
| put them in boxes, and mailed them to your customers -- the
best you could
| hope for would be a 30 percent improvement in productivity. In
order to do
| better than that, you have to change the way you think. "
| - Fred Brook [paraphrased] [as quoted from Allen Holub's
|
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html]
| ---
| [ comp.std.c++ is moderated.  To submit articles, try just
posting with ]
| [ your news-reader.  If that fails, use
mailto:std-c++@ncar.ucar.edu    ]
| [              --- Please see the FAQ before
             ]
| [ FAQ:
y.sgi.com/austern_mti/std-c++/faq.html              ]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]