Skip to main content
gamedev.net
🔒 Locked

Problem with std:map

Started by JoeyBlow2 9 replies 1.2k views
Original Post
JoeyBlow2
JoeyBlow2
I'm trying to insert an element into a std:map and I'm getting a crash. Can anybody tell me what I'm doing wrong? I've been looking at it for a few hours and I'm no closer to solving it (google isnt much help either.) 


LONG idWorkflow = 1;
QUEUES Queue;

m_Workflow.insert(WORKFLOW::value_type(idWorkflow, Queue));
The insert blows up. Here is my entire code: 


// This holds the Queues
typedef map<LONG, LONG> QUEUE; /* idQueue, QUEUEINFO */
typedef struct
{
  QUEUE Queue;
} QUEUES;

// This holds X number of Queues in workflows.
typedef map<LONG, QUEUES> WORKFLOW; /* idWorkflow, QUEUES */

//----------------------------------------

WORKFLOW    m_Workflow;
LONG        idWorkflow = 1;
QUEUES      Queue;

m_Workflow.insert(WORKFLOW::value_type(idWorkflow, Queue));
I also tried to remove the struct QUEUES and use QUEUE directly but that didn't help much at all either. Any ideas?
Fruny
Fruny
"blows up"?
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
krum
krum
Are you putting stuff into the map in a constructor of an object thats declared as a static object? If this is the case your object might be getting constructed and trying to add to a map that hasn't been constructed yet.
Drew_Benton
Drew_Benton 
#include <map>using std::map;// This holds the Queuestypedef map<long, long> QUEUE; /* idQueue, QUEUEINFO */typedef struct{  QUEUE Queue;} QUEUES;// This holds X number of Queues in workflows.typedef map<long, QUEUES> WORKFLOW; /* idWorkflow, QUEUES *///----------------------------------------int main( int argc, char* argv[] ){	WORKFLOW    m_Workflow;	long        idWorkflow = 1;	QUEUES      Queue;	m_Workflow.insert(WORKFLOW::value_type(idWorkflow, Queue));		return 0;}


That does not crash for me at all, so you have a logical error in your program elsewhere.
JoeyBlow2
JoeyBlow2
Drew:

Thanks.
I just did a test with your example and it works fine here too.
I'll keep looking.

Krum:

Nope

Fruny:

Yep, hits the catch on a try() catch.
Fruny
Fruny
Quote:
Original post by JoeyBlow2
Fruny:

Yep, hits the catch on a try() catch.


What exception?
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
JoeyBlow2
JoeyBlow2
Unhandled exception at 0x0045e78b in OSS.exe: 0xC0000005: Access violation reading location 0x00000004.
JoeyBlow2
JoeyBlow2
I just found out if I declare WORKFLOW variable local to where I do the insert it doesn't crash, but if I make it global or a private member of the class then it does.

Fruny
Fruny
That's not a C++ exception. It means you have a NULL pointer somewhere. Guessing from the 4 bytes offset, you are probably accessing the second member of a structure or second element of an array through a pointer, and the first is an int or similar-sized variable. I strongly doubt it is related to your map insertion.

You might also have an array overrun on a variable that precedes the map and are corrupting the map's internal data (e.g. overwriting it with zeroes).
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
JoeyBlow2
JoeyBlow2
Ok I got it to work by moving the initializing function into the class constructor rather than calling it during the ATL initializing section. There must be a conflict with ATL somehow, or the ATL function I'm initializing from.

Thanks for the help guys. I get it straighened up from here. I thought I was using STL incorrectly.
Nitage
Nitage
Spordic issues like this are usually caused by overwriting array bounds or otherwise accessing memory incorrectly.

Moving variable declarations and function calls around can appear to solve the problem as this can change the memory layout of variables.

It is very unlikely that you have actually solved the problem. Although it works now, it is likely to recur sporadically as you change your code until you find the root cause of the problem.

Are you compiling in release or debug mode? If it's in debug, try compiling in release to see if the problem reappears.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.