Thread: 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:

Code:

namespace{
	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:

Code:

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";
	return;
}

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:

Code:

	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:

Code:

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!

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: =========
/lib/tls/i686/cmov/libc.so.6[0xb7d93c42]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x90)[0xb7d94fc0]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0xb7f5c6a7]
/usr/lib/libstdc++.so.6(_ZNSs4_Rep9_S_createEjjRKSaIcE+0x61 )[0xb7f368c1]
/usr/lib/libstdc++.so.6[0xb7f37bc5]
/usr/lib/libstdc++.so.6(_ZNSsC1EPKcRKSaIcE+0x47)[0xb7f37d77]
./hdc[0x805c855]
./hdc[0x805ce45]
./hdc[0x805cf9e]
./hdc[0x805d40f]
./hdc[0x804b3bc]
./hdc[0x804b465]
./hdc[0x8049cbe]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7d3f050]
./hdc(__gxx_personality_v0+0x9d)[0x80495e1]
======= 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/libc-2.6.1.so
b7e6d000-b7e6e000 r--p 00143000 03:01 1946852 /lib/tls/i686/cmov/libc-2.6.1.so
b7e6e000-b7e70000 rw-p 00144000 03:01 1946852 /lib/tls/i686/cmov/libc-2.6.1.so
b7e70000-b7e73000 rw-p b7e70000 00:00 0
b7e73000-b7e7d000 r-xp 00000000 03:01 1749710 /lib/libgcc_s.so.1
b7e7d000-b7e7e000 rw-p 0000a000 03:01 1749710 /lib/libgcc_s.so.1
b7e7e000-b7ea1000 r-xp 00000000 03:01 1952803 /lib/tls/i686/cmov/libm-2.6.1.so
b7ea1000-b7ea3000 rw-p 00023000 03:01 1952803 /lib/tls/i686/cmov/libm-2.6.1.so
b7ea3000-b7f8b000 r-xp 00000000 03:01 997678 /usr/lib/libstdc++.so.6.0.9
b7f8b000-b7f8e000 r--p 000e8000 03:01 997678 /usr/lib/libstdc++.so.6.0.9
b7f8e000-b7f90000 rw-p 000eb000 03:01 997678 /usr/lib/libstdc++.so.6.0.9
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/ld-2.6.1.so
b7fcc000-b7fce000 rw-p 00019000 03:01 1161672 /lib/ld-2.6.1.so
bfa82000-bfa97000 rw-p bfa82000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
Aborted (core dumped)

Originally Posted by vart

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.

Thanks!