Thread: Writing To map<string,string> Causes Core Dump

  1. #1
    Registered User HalNineThousand's Avatar
    Join Date
    Mar 2008

    Writing To map<string,string> Causes Core Dump

    I have a program spanning 6-7 files. In one file I have an init routine that is called to initialize some of the variables in that section when a function in that file is first called. The variables are declared here:
    	bool keepReading = true, havecode = false, valueset = false;
    	char msgcode[16], msgtype[16], curmsg[2048];
    	unsigned int msglen = 0, msgin = 0, cktotal;
    	unsigned long naptime = 100;
    	string ctype = "", currentmsg;
    	vector<int> bq (256);
    	map<string,string> hdcmds;
    	map<string,string> hdcodes;
    	map<string,string> hdops;
    	map<string,string> hdband;
    	map<string,string> hdconstants;
    	map<string,string> hdformat;
    	map<string,string> hd90s;
    	map<string,string> hdvals;
    Then here is the function that initializes all the functions. There are 7 function calls included that get the map values from another location where I can call functions but can't access the variables:

    void loadhdlistendefs() {
    	if (valueset) return;
    	valueset = true;
    	hdcmds = get_hdcommands();
    	hdcodes = get_hdcodes();
    	hdops = get_hdoperations();
    	hdband = get_hdbands();
    	hdconstants = get_hdconstants();
    	hdformat = get_hdformat();
    	hd90s = get_hdscale();
    // 	cout << "DEBUG 1\n";
    // 	hdvals["x"] = "y";
    // 	hdvals["a"] = "b";
    // 	cout << "DEBUG 2\n";
    Note the 4 lines commented out at the end. More on those later.

    Now I have another routine that is called repeated. Overall, there is a endless loop in this file that will call a routine many times over and in that routine I have the following:

    	char xfer[10];
    //other stuff, including making sure there is a value in xfer.
    	hdvals["frequency"] = xfer;
    Now here's what's weird. If I leave the comments in the initialization function (loadhdlistendefs()), then when the repeating loop calls the routine that puts the value in hdvals (and this is the first time any value is put in hdvals), I get a core dump. If I uncomment BOTH assignment statements in the init function (or both and the 2 debug printouts), then everything works fine and there is no crash. If I uncomment only 1 of the assignment statements in loadhdlistendefs(), then the program will freeze up at some point in the endless loop. (I haven't yet tracked where, but I expect it to be the line that reads from a hardware device.)

    I've added this to the function that crashes:
    string ival2 = xfer;
    hdvals["frequency"] = val2;
    and it makes no difference. (I didn't expect it to.)

    Basically, if I don't set any values in the hdvals map in the initialization routine, then the first time I try to add a value to hdvals in the rest of the program it crashes. If I add only one value to hdvals in the init routine, then my program locks up. If I ad two values to the map in the init routine, then everything works like I'd expect.

    Why does setting these values make a difference in whether or not the program crashes later when I add a value to that hash?

    Thanks for any help!

  2. #2
    Jack of many languages Dino's Avatar
    Join Date
    Nov 2007
    Katy, Texas
    Got a crash report?

    From the outside, with just these minimal code snippets, it sounds like you have some function reading from the hdvals map, getting a null answer and subsequently crashing or hanging. When you intentionally initialize the map, there are values to read and process. Perhaps you have a timing issue somewhere, or you are not always taking into account that you might get a null value returned from hdvals.
    Mac and Windows cross platform programmer. Ruby lover.

    Quote of the Day
    12/20: Mario F.:I never was, am not, and never will be, one to shut up in the face of something I think is fundamentally wrong.

    Amen brother!

  3. #3
    Registered User HalNineThousand's Avatar
    Join Date
    Mar 2008
    I'm not reading from that map anywhere and I'm positive that when it crashes, it's when I'm writing to the map. Here's the debug output:

    *** glibc detected *** ./hdc: malloc(): memory corruption (fast): 0x08069d3e ***
    ======= Backtrace: =========
    /usr/lib/ )[0xb7f368c1]
    ======= Memory map: ========
    08048000-08065000 r-xp 00000000 03:03 426184 /home/hal/workspace/HD Radio Controller/hdc
    08065000-08066000 rw-p 0001d000 03:03 426184 /home/hal/workspace/HD Radio Controller/hdc
    08066000-08087000 rw-p 08066000 00:00 0 [heap]
    b7c00000-b7c21000 rw-p b7c00000 00:00 0
    b7c21000-b7d00000 ---p b7c21000 00:00 0
    b7d28000-b7d29000 rw-p b7d28000 00:00 0
    b7d29000-b7e6d000 r-xp 00000000 03:01 1946852 /lib/tls/i686/cmov/
    b7e6d000-b7e6e000 r--p 00143000 03:01 1946852 /lib/tls/i686/cmov/
    b7e6e000-b7e70000 rw-p 00144000 03:01 1946852 /lib/tls/i686/cmov/
    b7e70000-b7e73000 rw-p b7e70000 00:00 0
    b7e73000-b7e7d000 r-xp 00000000 03:01 1749710 /lib/
    b7e7d000-b7e7e000 rw-p 0000a000 03:01 1749710 /lib/
    b7e7e000-b7ea1000 r-xp 00000000 03:01 1952803 /lib/tls/i686/cmov/
    b7ea1000-b7ea3000 rw-p 00023000 03:01 1952803 /lib/tls/i686/cmov/
    b7ea3000-b7f8b000 r-xp 00000000 03:01 997678 /usr/lib/
    b7f8b000-b7f8e000 r--p 000e8000 03:01 997678 /usr/lib/
    b7f8e000-b7f90000 rw-p 000eb000 03:01 997678 /usr/lib/
    b7f90000-b7f97000 rw-p b7f90000 00:00 0
    b7fb0000-b7fb2000 rw-p b7fb0000 00:00 0
    b7fb2000-b7fcc000 r-xp 00000000 03:01 1161672 /lib/
    b7fcc000-b7fce000 rw-p 00019000 03:01 1161672 /lib/
    bfa82000-bfa97000 rw-p bfa82000 00:00 0 [stack]
    ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
    Aborted (core dumped)

  4. #4
    Hurry Slowly vart's Avatar
    Join Date
    Oct 2006
    Rishon LeZion, Israel
    malloc(): memory corruption
    seems to me you have a memory overrun somewhere in your code - it could even be not connected to the code where the crash occured
    All problems in computer science can be solved by another level of indirection,
    except for the problem of too many layers of indirection.
    David J. Wheeler

  5. #5
    Registered User HalNineThousand's Avatar
    Join Date
    Mar 2008
    Quote Originally Posted by vart View Post
    seems to me you have a memory overrun somewhere in your code - it could even be not connected to the code where the crash occured
    Okay, that makes a lot of sense because I just got through taking care of an uninitialized char* pointer elsewhere. What I can't believe is that the problem was caused by code I copied from a tutorial on how to read the serial port! I've never written a line of C++ until last week, so I'm learning pretty quickly and it's amazing how many tutorials out there have bad code in them! I did that other section on the first day or two that I was working on this, so I had no clue about it, then forgot about it until it caused other problems.


Popular pages Recent additions subscribe to a feed

Similar Threads

  1. having a core dump
    By justins in forum C Programming
    Replies: 6
    Last Post: 05-21-2008, 12:00 PM
  2. STL vector core dump
    By creativeinspira in forum C++ Programming
    Replies: 9
    Last Post: 07-22-2007, 04:49 PM
  3. What am I doing worng? Segmentation fault, core dump
    By cookie in forum C Programming
    Replies: 4
    Last Post: 06-08-2007, 09:59 AM
  4. Core Dump in While()
    By KrepNatas in forum C Programming
    Replies: 5
    Last Post: 05-17-2005, 11:15 AM
  5. core dump
    By kermit in forum Linux Programming
    Replies: 0
    Last Post: 08-03-2004, 06:25 PM