std::string, multithreading, and c_str

Started by
19 comments, last by yoshscout 16 years, 11 months ago
i really couldnt find much on the topic of unhandled exception: user breakpoint after researching it, i think the c_str function is causing issues with multithreading, there is no obvious blinking lights telling me that this is the problem but after 3 or 4 hours of adding thread safe critical sections through my whole engine, i am sure that the error is contained to where c_str is passed over to the D3DX functions. worse is that its pretty hard to find information about why an exception would be thrown without any information so what i have found after a LOT of research i feel like, getting an unhandled exception that says nothing more than user breakpoint is because of stack corruption. also it recommended to use pageheap to find out where this happened, however im going to take the std::string and wrap it out to a const char * that D3DX wants i think it will remove the issues, i will post back with results
Advertisement
That's not likely to solve anything, c_str() is going to return a const char* anyway.

The problem is likely much more subtle, you're obviously doing something naughty though. Trust me, it's your code, not the SC++L and not the D3DX library.

Why don't you post the code in question and provide a more detailed breakdown of the problem as you observe it?
The pointer returned by c_str is invalid as soon as you call any non-const methods of the string. If multiple threads are accessing the string simultaneously, you need to ensure that no thread calls a mutating method while another thread is using the pointer from c_str.
You need to provide more information to better diagnose the problem.

If you are using Visual Studio you should read http://msdn2.microsoft.com/en-us/library/c9ceah3b(VS.71).aspx about the thread safety guarantees.

If you are linking against the Multi-threaded CRT then you have some basics guarantees, but if you plan to read/write the string from multiple threads you need to provide a readers/writers lock or similar construct. You might even want to wrap std::string into a thread safe class for reading and writing. Or you can redesign your application to avoid dealing with global strings.

It is also possible that this has nothing to do with multithreaded and could be a problem with your code/logic. Writing code multi-threaded architectures and code is a non-trivial task.
the errors are not contained to any one set of code, the are all over the place something is corrupting the heap somewhere its not the c_str(i knew if i called certain functions it was void but there was no movement) like i was thinking there are a few places it is happening frequently but every build the exception is thrown at a different place. im locking resources like i should be so somewhere i have some stray function jacking things up and its not getting caught until way later it frequently happens on my calls to present the scene, or create resources via D3DX

for clarification all my resources, including the D3D Device have critical sections that are locked in wrapper functions, but most of the time my second thread(resource loader) is sleeping while the exception is thrown anyways
"unhandled exception that says nothing more than user breakpoint ", most code generators fill up unused code regions with the instruction int 3; (x86) which is a user breakpoint, this makes it possible to catch cases in which you jump to an invalid code address.

Your instruction pointer or your return address (which lives on the stack) are pointing to the wrong address, this could be caused by stack corruption, but could also be caused by other reasons.
Are you using DX for rendering?
Are you loading resources on one thread and using them on another?
Do you use the multi-threaded flag when you create the device?
awesome information, so it is stack corruption, the question is how to debug stack corruption, its not exactly like debugging a regular code issue normally u breakpoint where problem function occurs, then u just step through watching values and see where math went wrong or how you ended up with NULL pointer, this is totally different
D3DCREATE_HARDWARE_VERTEXPROCESSING | D3DCREATE_MULTITHREADED

yes resources loader on one thread everythign else on other thread for now
CDOResource::CDOResource(){	Priority = 500;	m_bValid = false;	InitializeCriticalSection(&Crit_sect);}CDOResource::~CDOResource(){	DeleteCriticalSection(&Crit_sect);}bool CDOResource::Load(){	return true;}void CDOResource::Free(){}bool CDOResource::Lock(){	EnterCriticalSection(&Crit_sect);	if(m_bValid)		return true;	return false;}void CDOResource::ReleaseLock(){	LeaveCriticalSection(&Crit_sect);}

This topic is closed to new replies.

Advertisement