problems with std:set


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 8 of 8

Thread: problems with std:set

  1. #1
    Sorin Gherman Guest

    problems with std:set


    I've encountered a strange problem with std::set : I need to work with collections
    of a custom defined Node objects. Actually Node is just an interface (abstract
    class), but the collections should handle pointers to Node. (So it's out
    of the question to pass Nodes by _value_ instead of pointers)

    I had no problems with std::vector<const Node *> and
    std::map<const Node *, SomeOtherClass>, but I ran into problems with std::set<const
    Node *>: using the MSVC++ version 6.0's STL implementation, the release version
    generates an AccessViolation when I call for the first time the insert method
    of std::set.
    All pointers/objects are valid, and in the debug version there is no such
    problem.

    I should also mention that I use the STL as a runtime dll, it's not linked
    statically into my project.

    Does anybody have a hint on why is this happening?

    Thanks in advance,
    Sorin Gherman

  2. #2
    Danny Kalev Guest

    Re: problems with std:set



    Sorin Gherman wrote:
    >
    > I've encountered a strange problem with std::set : I need to work with collections
    > of a custom defined Node objects. Actually Node is just an interface (abstract
    > class), but the collections should handle pointers to Node. (So it's out
    > of the question to pass Nodes by _value_ instead of pointers)
    >
    > I had no problems with std::vector<const Node *> and
    > std::map<const Node *, SomeOtherClass>, but I ran into problems with std::set<const
    > Node *>: using the MSVC++ version 6.0's STL implementation, the release version
    > generates an AccessViolation when I call for the first time the insert method
    > of std::set.
    > All pointers/objects are valid, and in the debug version there is no such
    > problem.
    >
    > I should also mention that I use the STL as a runtime dll, it's not linked
    > statically into my project.


    I suspect that this is the problem: the Node pointers belong to one
    address space and the set uses a different heap (the dll's heap). Try to
    use static linking and see whether it solves the problem.

    Danny Kalev
    >
    > Does anybody have a hint on why is this happening?
    >
    > Thanks in advance,
    > Sorin Gherman


  3. #3
    Sorin Gherman Guest

    Re: problems with std:set


    >I suspect that this is the problem: the Node pointers belong to one
    >address space and the set uses a different heap (the dll's heap). Try to
    >use static linking and see whether it solves the problem.


    It's very strange then, cause replacing the std::set with a std::vector
    solved the access-violation...

    And what do you mean with the different address-spaces? I thought using
    set<const Node *> would be actually equivalent to set<int> (assuming a pointer
    is represented with an int). Where is the memory management problem, since
    no allocation/deallocation takes place?
    The crash happened at the set::insert call, which would just store an
    int in the internal set structure...or am I wrong?

    Thanks,
    Sorin


  4. #4
    Danny Kalev Guest

    Re: problems with std:set



    Sorin Gherman wrote:
    >
    > >I suspect that this is the problem: the Node pointers belong to one
    > >address space and the set uses a different heap (the dll's heap). Try to
    > >use static linking and see whether it solves the problem.

    >
    > It's very strange then, cause replacing the std::set with a std::vector
    > solved the access-violation...
    >
    > And what do you mean with the different address-spaces? I thought using
    > set<const Node *> would be actually equivalent to set<int> (assuming a pointer
    > is represented with an int). Where is the memory management problem, since
    > no allocation/deallocation takes place?
    > The crash happened at the set::insert call, which would just store an
    > int in the internal set structure...or am I wrong?


    Can you post some of your code? Many things can go wrong, for instance,
    if you try to later a Node object through a const pointer, or if you
    attempt (either explicitly or implicitly) to dereference a Node * in the
    dll's address space. a pointer is not the same as int, although they
    happen to be represented in the same way. While a value of 10 is valid
    for int, assigning it to a pointer is most likely a bug and cause a
    crash. The fact that the crash happens when you call insert() doesn't
    provide enough info because the problem may have occurred earlier, and
    it manifests itself only then. Besides, the insert() member function
    usually performs many intricate operations that have to do with
    allocating memory, moving objects around and releasing the original
    buffer (in case of reallocation). you need to step into it to see where
    exactly the crash occurs.

    Danny

  5. #5
    Jim Osborne Guest

    Re: problems with std:set


    Using node as a abstract class... hmmm. Sounds like an interesting project.

    Here are a couple of more ideas to try. Did you cross check your compilers
    configuration between debug and release modes... particularly the RTTI switch?
    Given your code works in debug and not in release mode this seems to be a
    reasonable place to start. Also have you considered using try/catch to help
    diagnose this problem?

    "Sorin Gherman" <s_gherman@yahoo.com> wrote:
    >
    >I've encountered a strange problem with std::set : I need to work with collections
    >of a custom defined Node objects. Actually Node is just an interface (abstract
    >class), but the collections should handle pointers to Node. (So it's out
    >of the question to pass Nodes by _value_ instead of pointers)
    >
    >I had no problems with std::vector<const Node *> and
    >std::map<const Node *, SomeOtherClass>, but I ran into problems with std::set<const
    >Node *>: using the MSVC++ version 6.0's STL implementation, the release

    version
    >generates an AccessViolation when I call for the first time the insert method
    >of std::set.
    >All pointers/objects are valid, and in the debug version there is no such
    >problem.
    >
    >I should also mention that I use the STL as a runtime dll, it's not linked
    >statically into my project.
    >
    >Does anybody have a hint on why is this happening?
    >
    >Thanks in advance,
    >Sorin Gherman



  6. #6
    Sorin Gherman Guest

    Re: problems with std:set


    >Here are a couple of more ideas to try. Did you cross check your compilers
    >configuration between debug and release modes... particularly the RTTI switch?
    >Given your code works in debug and not in release mode this seems to be

    a reasonable place to start.

    The RTTI switch is on, we need that to be so. I didn't check much of the
    release version optimizations and so, I expected that the simple construction
    I used to work without problems, but it's not the case :(
    Actually the compile time is already pretty long, experimenting randomly
    with various settings is not something I enjoy. I prefer to understand what's
    causing the problem exactly, rather than just make it work for the moment
    (an get similar problems later).

    >Also have you considered using try/catch to help
    >diagnose this problem?


    Hmmm...no, but what would you catch in this case?

    Thanks for the answer,
    Sorin Gherman

  7. #7
    Sorin Gherman Guest

    Re: problems with std:set


    Here is the relevant code:

    const tree::Node * tmpNode = pTree->GetRoot(); // that's implemented in a
    separate dll, tree.dll
    while ( tmpNode !=0 )
    {
    REM::RulesNodeSelection selection; // that's in rules.dll
    selection.AddNode( tmpNode ); // this causes a crash in the release
    mode, at the very first while iteration
    .... // use selection object here
    tmpNode = nextNodeIter( tmpNode );
    }

    RulesNodeSelection::AddNode has a call:
    fNodes.insert( pNode );
    where:
    typedef std::set<const Node*> NODES_SET;
    NODES_SET fNodes;

    I've discovered "fNodes.insert( pNode )" is the ultimate call that causes
    the crash.... but fNodes is valid and pNode looks valid (even if the later
    wouldn't be valid, it still is just an integer for now, right? Until I try
    to use it as a pointer...).

    Since replacing set with a vector was OK, I assume it's not an earlier mistake
    that's manifesting there, but is something wrong with the std::set...

    What do you think?

    Thanks,
    Sorin

    >Can you post some of your code? Many things can go wrong, for instance,
    >if you try to later a Node object through a const pointer, or if you
    >attempt (either explicitly or implicitly) to dereference a Node * in the
    >dll's address space. a pointer is not the same as int, although they
    >happen to be represented in the same way. While a value of 10 is valid
    >for int, assigning it to a pointer is most likely a bug and cause a
    >crash. The fact that the crash happens when you call insert() doesn't
    >provide enough info because the problem may have occurred earlier, and
    >it manifests itself only then. Besides, the insert() member function
    >usually performs many intricate operations that have to do with
    >allocating memory, moving objects around and releasing the original
    >buffer (in case of reallocation). you need to step into it to see where
    >exactly the crash occurs.
    >
    >Danny



  8. #8
    Jim Osborne Guest

    Re: problems with std:set


    One common procedure with access violations is to use the call stack window
    in debug to find corrupted data being passed as a parameter to function.
    Given your code works in the debug mode this approach presents a problem.
    I would therefore be inclined to produce some kind of diagnostic output,
    whether that be try/catch or simply 'cout << &object' to help isolate the
    problem.

    Fortunately for you I am at the limit of my expertise and can not hinder
    this conversation further.

    "Sorin Gherman" <s_gherman@yahoo.com> wrote:
    >
    >>Here are a couple of more ideas to try. Did you cross check your compilers
    >>configuration between debug and release modes... particularly the RTTI

    switch?
    >>Given your code works in debug and not in release mode this seems to be

    >a reasonable place to start.
    >
    > The RTTI switch is on, we need that to be so. I didn't check much of

    the
    >release version optimizations and so, I expected that the simple construction
    >I used to work without problems, but it's not the case :(
    > Actually the compile time is already pretty long, experimenting randomly
    >with various settings is not something I enjoy. I prefer to understand what's
    >causing the problem exactly, rather than just make it work for the moment
    >(an get similar problems later).
    >
    >>Also have you considered using try/catch to help
    >>diagnose this problem?

    >
    > Hmmm...no, but what would you catch in this case?
    >
    >Thanks for the answer,
    >Sorin Gherman



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center