Need help understanding crash (using WinDbg)
-
Thousands of people use my program, and about every week a crash report is sent to me with the same details. Here's a picture showing the info from WinDbg: http://www.igx89.com/crash1.jpg[^] (LogString is bound to an Edit Control using DDX_Text) I can't figure out why that crash would be happening, and would greatly appreciate any help given to me.
-
Thousands of people use my program, and about every week a crash report is sent to me with the same details. Here's a picture showing the info from WinDbg: http://www.igx89.com/crash1.jpg[^] (LogString is bound to an Edit Control using DDX_Text) I can't figure out why that crash would be happening, and would greatly appreciate any help given to me.
ive had some problems concatnating cstrings in some programs... i never figured out y, but it happened very often, cause it was in a function used many times per second. The same code in another part of the program worked fine! The stupid part was that if i added some code in the same funtion, the problem disapeared! Seemed like a compiler error, maybe because of optimizations :confused:
-
Thousands of people use my program, and about every week a crash report is sent to me with the same details. Here's a picture showing the info from WinDbg: http://www.igx89.com/crash1.jpg[^] (LogString is bound to an Edit Control using DDX_Text) I can't figure out why that crash would be happening, and would greatly appreciate any help given to me.
The second use of + on that line appears to have faulted - you haven't shown the disassembly of
ATL::operator+, but if my copy of VS.NET has generated similar code, it looks like you've trashed the second argument,LogString. You probably have a wild write somewhere in your program. Stability. What an interesting concept. -- Chris Maunder -
The second use of + on that line appears to have faulted - you haven't shown the disassembly of
ATL::operator+, but if my copy of VS.NET has generated similar code, it looks like you've trashed the second argument,LogString. You probably have a wild write somewhere in your program. Stability. What an interesting concept. -- Chris MaunderThe only place where that variable is accessed is in the DDX call and in the function shown, so the variable should always be valid. I could probably work around the problem by using strcpy and strcat functions instead, but I'd rather discover the root of the problem so I don't have to worry about bugs like this popping up again in the future.
-
Thousands of people use my program, and about every week a crash report is sent to me with the same details. Here's a picture showing the info from WinDbg: http://www.igx89.com/crash1.jpg[^] (LogString is bound to an Edit Control using DDX_Text) I can't figure out why that crash would be happening, and would greatly appreciate any help given to me.
Is your Log() function called from its own thread or from multiple threads ? One chance for the err can be : In your code each time you concat CString the heap has to be locked/unlocked multiple times.If this is hapenning from multiple threads it again induces context switching. Note: CString is not supposed to be shared between threads.
It's not a bug, it's an undocumented feature.
suhredayan@omniquad.commessenger :suhredayan@hotmail.com
-
The only place where that variable is accessed is in the DDX call and in the function shown, so the variable should always be valid. I could probably work around the problem by using strcpy and strcat functions instead, but I'd rather discover the root of the problem so I don't have to worry about bugs like this popping up again in the future.
I assume
LogStringis a member of theCFLModManagerclass. I don't think your problem is with a legitimate access; I think something else is corrupting the object. Possibilities I can think of are: you're using theCFLModManagerobject after it's been deleted (if you're using new/delete to manage the object), or from another thread or routine outside the scope of the function that declares the object (if it's a local variable), or that you have an unbounded ('wild') write somewhere which is overwriting the memory used by theLogStringobject. The first two cases are relatively easy to check for. The last really requires examining every memory access in the program that could possibly coincide with the life-time of the dialog box. You can help yourself out a little by putting a data breakpoint on theLogStringmember and see when it changes. Specifically, it appears to be them_pszDatamember that's been corrupted. Stability. What an interesting concept. -- Chris Maunder -
I assume
LogStringis a member of theCFLModManagerclass. I don't think your problem is with a legitimate access; I think something else is corrupting the object. Possibilities I can think of are: you're using theCFLModManagerobject after it's been deleted (if you're using new/delete to manage the object), or from another thread or routine outside the scope of the function that declares the object (if it's a local variable), or that you have an unbounded ('wild') write somewhere which is overwriting the memory used by theLogStringobject. The first two cases are relatively easy to check for. The last really requires examining every memory access in the program that could possibly coincide with the life-time of the dialog box. You can help yourself out a little by putting a data breakpoint on theLogStringmember and see when it changes. Specifically, it appears to be them_pszDatamember that's been corrupted. Stability. What an interesting concept. -- Chris MaunderYes, it's a member of the main dialog class, CFLModManager. I don't see how the first case would be possible; the second case might, I guess, but I just have one other thread, and it just communicates using SendMessage to the main thread's window. I'll try changing it to PostMessage (not sure if that'll do anything), and increasing a couple buffers that aren't CString's (I doubt they're overflowing, but just to be sure). What makes this crash so hard to debug is that I can't duplicate the crash, and it rarely happens to my users; ~1 crash a week (auto-reported) out of 10,000+ downloads. Fortunately, because it's so rare, it won't be that big of deal if I can't fix it; I don't think it's happened to the same person more than once.
