Click here to Skip to main content
15,740,865 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:

Have a queue of CString's with size 30000. I am grabbing the data one by one.



while (!DataQueue->empty())
	CString sTimeStamp = DataQueue->front();
	char* pChar = T2A(sTimeStamp);
	//do something with pChar

The application is crashing throwing up a stack overflow error. If i remove the piece of code "char* pChar = T2A(sTimeStamp);", there is no error thrown and everything works fine. I think that the Char* line is having a memory leak or the memory is not freed and there by causing the complete usage of heap memory before the queue iteration completes.

This is all what i have tried with in the while loop but nothing worked, the application still crashes:
char* pChar = sTimeStamp.GetBuffer(0);

char* pChar = T2A(sTimeStamp.GetBuffer(0));

char* pChar
pChar = sTimeStamp.GetBuffer(sTimeStamp.GetLength());

char* pChar
strcpy(pChar, (LPCTSTR)sTimeStamp);

char*	pChar1 = new char[];
delete [] pChar;

How do i solve the stack overflow error?
Updated 19-Aug-13 16:34pm
Sergey Alexandrovich Kryukov 19-Aug-13 17:25pm    
Debugger. Usually it's fairly simple. Your code does not reveal the problem.

The code sample you show does not reveal the problem. Usually, this problem is easy enough to solve.

Almost 100% of certainty that this is result of "infinite" recursion or mutual recursion:[^],[^].

Such problems can be resolved in a very systematic way using the debugger. First, you observe where the exception is thrown. Put a break point before it happens and use the debugger window "Call stack". You will see where the calls come from. Find out the reason for infinite recursion and devise a correct condition of exit from recursion. Usually, the bug can be found very quickly if you combine debugging with simple logic.

You make an initial guess on at least one method which is attempted to get called "infinite" number of times. Usually it does not take long to find such place. You put break point(s) on a very beginning of such method(s) and try to confirm it happens. When the execution is stopped on a breakpoint, you can go up the stack or down the stack. It's more effective to go down: you keep the breakpoint and debug just one this method stepwise, making big steps at first, until you catch the same method being called deeper in stack (remember your breakpoint is still there). When it happens, you start over and go in smaller step until you pinpoint where the recursion goes. This time try to figure out why the condition of the recursion end is never met. At the same time you move your breakpoint(s) closer to the source of recursive call, narrowing your net.

It may sound difficult, but with little practice always gives 100% results, unlike the cases with different bugs of some unknown nature. In case of stack overflow, you can be 100% sure that you can find the problem before you start looking.

Share this answer
pasztorpisti 19-Aug-13 17:31pm    
+5, and good luck in persuading them to use a debugger! :-)
Sergey Alexandrovich Kryukov 19-Aug-13 17:37pm    
I tried my best, thank you. :-)
[no name] 19-Aug-13 19:34pm    
Good answer pointing OP in right (only) direction. I smell a missing NULL terminator.
Sergey Alexandrovich Kryukov 19-Aug-13 19:37pm    
Thank you. Hm... I don't know how missing terminator can cause stack overflow, unless this is a recursion terminator... :-)
amarasat 20-Aug-13 9:32am    
Thanks for your time SA. Unfortunately i tried debugging and i am sure Char* is causing the issue but don't know how to solve.
The documentation of T2A tells you that it allocates its space for storing the converted character string from the stack. Any yes, this space is not returned until you exit the function. If you call T2A in a loop it will grab more an more of the stack until you finally reach a stack overflow. And that is what typically happens.

Solution: Don't use T2A but a single local buffer that you allocate yourself and convert into that buffer. The same buffer can be used in each iteration of the loop.
Share this answer
CPallini 20-Aug-13 4:26am    
nv3 20-Aug-13 4:52am    
amarasat 20-Aug-13 9:31am    
Thanks for the help nv3, i had problems in understanding local buffer, but Jochen's answer solved it.
nv3 20-Aug-13 10:23am    
You are welcome.
Solution 2 from nv3 explains what is wrong.

When using the CString class anyway, you can use CStringA which supports conversion from Unicode to ANSI with the assignment operator:
while (!DataQueue->empty())
    // This assumes that DataQueue is a CString list
    // Then GetString() must be used to have a LPCTSTR
    CStringA sTimeStamp = DataQueue->front().GetString();
    // Get a const ptr
    // Use GetBuffer() instead if the string should be modified
    const char* pChar = sTimeStamp.GetString();
Share this answer
amarasat 20-Aug-13 9:29am    
Oh my God,

Thanks a lot for your solution. It has worked and solved my stupid stackoverflow problem that i have been sitting for almost a day. This is what i am trying to search online, some method to construct the Char* which does not cause StackOverFlow.
Jochen Arndt 20-Aug-13 10:53am    
Glad to here that it is working now. I hope you understand the problem described by nv3. My solution is what he suggested: The CStringA variable is the local buffer for the converted string.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900