RE: [Dev-C++] STL Map question

[Per W. <pw...@ia...>]

Ioannis:
For older compilers, new doesn't throw an exception. Depending on
configuration and/or implementation, they either return NULL, call an
installable callback function or kill the program.

The implementation of user handling might be absolutely bug-free. It
doesn't help if some other part of the program somehow goofs up and
somehow overwrites memory.

A dual delete on an object somewhere in the program is a perfect example
of how a program without any strange pointer manipulation might perform
memory overwrites, by destroying the heap.

Shane: Have you tried some heap-debugging code, that checks the following
for every memory release:
- that it is a validly allocated pointer
- that the memory hasn't already been released
- that guard bytes of the block hasn't been overwritten.

/Per W

On Sat, 12 Jul 2003, Ioannis Vranos wrote:

> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of Shane Bryldt
> > Sent: Friday, July 11, 2003 11:53 PM
> > To: Hossein Haeri
> > Cc: C++
> > Subject: Re: [Dev-C++] STL Map question
> >
> >
> > Actually, since I had about 20 responses on this topic, none of which
> > actually got close to the effect, nevermind the cause of the
> > problem, I will
> > try and explain the situation in more detail.  However, to
> > make the records
> > clear, I don't expect to find an answer now.  I have looked
> > the code over a
> > number of times, and had another expert which is admittedly
> > significantly
> > better with C++ and STL than myself, and even he cannot seem
> > to find any
> > problems which relate.  Given old working code, and my new
> > adjusted code,
> > many changes were made but I cannot determine what is causing
> > the problem.
> >
> > Now, the effect of the issue, is as follows. A network of 6,000-10,000
> > active users at any given time is regulated by a security
> > service.  This
> > service runs and connects like a user, with special
> > priviledges.  Anytime a
> > user connects to the network, the services is informed, and
> > the User is
> > added to a global UserList.  The network also has smaller
> > units, known as
> > Channels.  Each Channel contains 3 UserList's as well.
> > First, depicts all
> > users in the Channel, the second depicts all the operators of
> > the channel,
> > and the third depicts the priviledged users who are not
> > operators.  99% of
> > the time, the code work fine.  Users constantly added and
> > removed from the
> > list.  Periodically, what seems like an issue without a
> > pattern, the code
> > will crash with a segmentation fault while trying to call
> > "std::map<>::find()", with a valid key.  Whether the key is
> > in the map, is
> > not definate, but the key passed in valid and should not have
> > a problem
> > being searched.
> >
> > This said, I have narrowed the issue down to one of 2 causes.
> > 1) Either
> > User's are being added to lists, and not being removed, and
> > the UserLists
> > are eventually gathering enough garbage that out of memory is being
> > encountered.
>
>
> In this case if you use the operator new as you should, an std::bad_alloc()
> exception would be thrown (defined in <new>) and as you should you must have
> at least a catch(std::bad_allloc) in main() to catch such exceptions and at
> least make the problem known by displaying an error message and shutting
> down the program properly).
>
>
>
>
> > The application has a signal hook for out of
> > memory, and it is
> > not being raised.
>
>
> Let's hope you mean a catch clause.
>
>
>
> > So I am leaning more towards option 2) The
> > User class is
> > being deleted, without being removed from the UserList.
> > However, I can find
> > no indication of this in the code.  The code is many
> > thousands of lines, it
> > is not a small project by any means.  Providing the source
> > for the issue,
> > would require the entire project as the issue is not
> > specifically a syntax
> > issue, but rather a situational issue.  I do believe something has
> > invalidated a User class, which a UserList has a pointer to,
> > and when trying
> > to use it, is causing a segmentation fault.  I'm sure most of
> > the experts
> > here will agree with my conclusion and realize tracing this
> > problem is no
> > easy task.
>
>
> We must see at least the entire definitions of UserList and User. Can you
> provide them?
>
>
>
> > I've considered some commercial products like Purify, or some
> > other memory
> > tracking products, but I have no experience with any, since
> > I've never had
> > an issue I couldn't resolve purely with GDB.  Since the
> > problem traces back
> > most likely to an invalid pointer reference, does anyone have
> > suggestions on
> > how I could possibly detect where the pointer is being deleted?
>
>
>
> I am not an expert, I am still learning (and unfortunately there is an
> infinite number of things that I want to learn) but I think that if there
> has been a more proper use of C++, the code would have been more bullet
> proof. That is using the superior alternatives that C++ provides instead of
> the old stuff that they exist to replace.
>
>
>
>
> >  I've
> > considered the idea of using smart pointers to track the
> > issue down, but
> > again I'm not entirely certain of how to implement some code
> > to track where
> > the User is being deleted without being removed from the
> > channels they are
> > in... It could also potentially be an issue with overwritting
> > memory, but
> > with how often it is caused in exactly the same way, it's
> > unlikely to be
> > memory overbounding.
> > I noticed a location where the key being used was being changed (a
> > nickname), and in those cases, where the old code would just
> > rename the
> > nickname, I have now remove from the map and then readd to
> > the map. When it
> > tries to remove from the map is when it crashes.  I can only
> > assume that the
> > problem is an invalid pointer, thus the map::find function is crashing
> > because of invalid memory.  The key was based on a const char
> > *, but the
> > other expert I consulted suggested using std::string to help track the
> > problem until it is found... Changing to use std::string is
> > how I determined
> > that the key was still valid (because it had a copy of the
> > nick instead of a
> > pointer to the nick which may be invalidated at some point),
> > and the key was
> > still intact as far as I can remember, the pointer however
> > caused GDB itself
> > to indicate that the program crashed again from a call by
> > GDB, when trying
> > to access a member of the pointer.
> >
> >
> > Okay, hopefully these details will clarify for all the people
> > who tried to
> > help... The problem itself is not something so simple as was
> > suggested so
> > far.  However, Hossein did make one point that I should have realized
> > myself.  Not that it matters, but I should use empty()
> > instead of size() ==
> > 0, since it's possible empty() can execute faster than
> > size().
>
>
> Eh? Why? Both have the same speed, actually empty is usually
>
> // inside the class definition
> bool empty() const {  return size()==0; }
>
>
> since map has to keep track of its size. In any case consider them as equal
> (an equality comparison doesn't take time!).
>
>
>
> >  But speaking
> > from the ANSI compliance, size() == 0 is identical to empty()
> > == true in
> > result, just not exection.  That said, it will not affect the problem.
>
>
> Yeap. Please provide us with the complete defintions of User and UserList.
> :-)
>
>
>
>
>
>
> Ioannis Vranos
>
> * Programming pages: http://www.noicys.freeurl.com
> * Alternative URL 1: http://run.to/noicys
> * Alternative URL 2: http://www.noicys.cjb.net
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>