sprintf stackdumps on second call to class method -- first call fine...

[eriks]

Again, I have another post here on CPP where it might just be my ignorance of C++ (I'm an old C hacker in days past) or maybe it's just Cygwin, but I thought I would post anyway and make sure my understanding of heap and stack space is correct, but...

Here's a method call on a class that uses sprintf() and it blows up the second time I call it. I'm certain the rest of the class isn't necessary for providing enough insight into the issue:

void MyLog::log( const char *msg ) const {
   char *logMsg;
   if (privateMemberDebug) {
      sprintf( logMsg, "My Log Format String: %s", msg );
      std::cerr << logMsg << std::endl;
   }
}

The first time I call myLog.log() I'm fine. The second time, I get a stack dump. Now, I'm expecting logMsg to get allocated on the heap. I'm expecting the memory for *logMsg to be allocated on the heap for whatever size *msg is plus the format string, plus the null. I'm expecting when the method is completed that the memory is returned to the heap and the data that was there is now junk. The next time I call the routine, I expect the same thing to happen again, fresh.

But the routine clearly stack dumps on the sprintf() call the second time it's called. The first time, the memory @ *logMsg is "clean." The second time it's junk. I would expect in theory for that memory allocated to be considered junk every time, but for sprintf() to allocate the space it needs, plus the format string, plus msg, plus the null every time and then release that back to the heap when done.

With more modern languages (sorry to put it that way!), I haven't had to think this way in a long time, so I wanted to get my facts straight here. I see no reason why that code shouldn't work time and again.

Or maybe again, this is all Cygwin and I should move to a different environment. :-) Or maybe there is a compiler optimization here for logMsg I'm not taking into account that somehow makes the allocations more "static" (without using a static modifier??).

-eriks

(In reality, my format string is a tad more complicated. This is why I don't just build the output using iostream operators, cout, cerr, endl, etc.)

[helios]

I'm expecting logMsg to get allocated on the heap.

You're never making logMsg point to anything and there are no calls to malloc() or new being performed.

I'm expecting the memory for *logMsg to be allocated on the heap for whatever size *msg is plus the format string, plus the null.

No. Just no. No form of memory allocation works that way. The size of what you want to allocate must be known beforehand.

I'm expecting when the method is completed that the memory is returned to the heap and the data that was there is now junk.

Neither C nor C++ provide garbage collection. If you don't manually free something before all pointers to it are lost or reassigned, it becomes a memory leak.

I'm actually surprised the program didn't crash and burn the first time.