|
Roger Allen wrote: Sometimes also see text saying that a block at
has been modified after being freed at
+offset
To my knowledge the only way a software keeps track of this and report it with the words you've quoted above, is if it uses the MFC framework built with new defined to DEBUG_NEW.
It could be that DEBUG_NEW is used instead of the ordinary new operator.
It would use the allocator from the release built CRT, but with extra info and boundary checks when released. You'll get more info on this from the link I provided in my previous post.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: To my knowledge the only way a software keeps track of this and report it with the words you've quoted above, is if it uses the MFC framework built with new defined to DEBUG_NEW.
It could be that DEBUG_NEW is used instead of the ordinary new operator.
mmm thats an interesting point. I will check the whole app for that one.
I went through PJ's article on the release build. Its something I have read before but its been a while. A few updates etc in it but nothing jumped out from it as a possible cause of the issues were seeing.
If you vote me down, my score will only get lower
|
|
|
|
|
Roger Allen wrote: I will check the whole app for that one.
Well, how did it go? Found anything suspicious?
A missing #ifdef _DEBUG perhaps?
Roger Allen wrote: I went through PJ's article on the release build.
Ummm, "PJ"? What article is that? Or you mean "Professor Joe"? 
Nevertheless, one thing to look for when the debug version does what it's supposed to and the release version does not, is uninitialized variables. A lot of them get initialized in the debug version behind curtains.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Ummm, "PJ"? What article is that? Or you mean "Professor Joe"?
For some reason I had it my head it was by PJ Naighter, its Actually by Joesph Newcomer 
Roger Stoltz wrote: Nevertheless, one thing to look for when the debug version does what it's supposed to and the release version does not, is uninitialized variables. A lot of them get initialized in the debug version behind curtains.
Its something were checking also. Its slowely being escalated to the whole team looking for it.
If you vote me down, my score will only get lower
|
|
|
|
|
It would be nice to know if, or rather when, you find something.
I'm curious and it would be a good experience for myself as well; another pitfall to avoid and possibly how to do it.
Good luck in your hunt for that illusive bug. 
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: It would be nice to know if, or rather when, you find something.
I'm curious and it would be a good experience for myself as well; another pitfall to avoid and possibly how to do it.
Good luck in your hunt for that illusive bug.
Should we ever track it down I will post a message in this thread.
We have exhausted most conventional methods of tracking it atm. Were building a test suite now which will setup the same conditions which will allow us to remove/add sections as we go to see where the unwanted interaction is occuring.
If you vote me down, my score will only get lower
|
|
|
|
|
We think we may have now tracked the problem down.
Seems its not our bug 
http://support.microsoft.com/kb/813810[^]
Apparently the VC6 implementation of std::string is not that multiprocessor/thread safe 
[edit]
And yes, following one of the suggestions in the article fixed our problem. Now we need to decide which way we want to do the fix in the final product.
[/edit]
If you vote me down, my score will only get lower
|
|
|
|
|
Roger Allen wrote: And yes, following one of the suggestions in the article fixed our problem.
Nice. Congratulations to you and your team.
Well done Roger!
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Roger Stoltz wrote: Ummm, "PJ"? What article is that? Or you mean "Professor Joe"?
PJ Naughter[^]... He used to be a very active member of Codeproject.com many years ago. After he created his own website[^] he stopped updating his articles and rarely visits anymore. There are some excellent libraires available on his website. Microsoft awarded him with MVP status in 2007[^] due to his contributions.
Best Wishes,
-David Delaune
|
|
|
|
|
Well, I found PJ's site about a decade ago when I had a job I resigned from in 2000.
But I couldn't remember whether he had written something about the differences between the debug and release versions. That combined with the fact that I linked to Joe's site made me unsure about what the other Roger meant.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
- Are you using a multi-threaded C run-time (I'm sure you are, but am asking for completeness
 ) - Are the STL objects being allocated in the same module (EXE/DLL) as they're destructed in? If not, you need to ensure you build all your different modules with a DLL version of the C run-time.
#2 has caused the same symptoms for me in the past as you're experiencing.
|
|
|
|
|
Stuart Dootson wrote: Are you using a multi-threaded C run-time (I'm sure you are, but am asking for completeness )
Yes, they all use the Multithreaded DLL for CRT etc. Double and triple checked.
Stuart Dootson wrote: Are the STL objects being allocated in the same module (EXE/DLL) as they're destructed in? If not, you need to ensure you build all your different modules with a DLL version of the C run-time.
I beleive they are all allocated/destructed in the same module, but they do all use the same Multithreaded DLL
At the moment were suspecting a hidden shared variable somewhere and combing the entire application for any file scope variables that should have been declared const which arn't.
1 suspect vector of objects has been found but that was before lunch and hasn't been fully investigated yet.
If you vote me down, my score will only get lower
|
|
|
|
|
My gut instinct is buffer overruns. Get an eval copy of BoundsChecker and run your stuff through it.
(And if doing a lot of new/delete, consider going to fixed, preallocated buffers.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
We have an old copy of boundschecker 7 which I installed and tried to test the application with. Unfortunately since it was released there have enough changes to stop it from working.
It doesn't report any issues and fails to catch any kind of problem on my system. Trying to get hold of an eval version of BC 9 atm.
Joe Woodbury wrote: My gut instinct is buffer overruns.
Its an odd one as if it was something like this I would expect it to happen when just a single calculation is run. It only happens when we have 2 running concurrently.
If you vote me down, my score will only get lower
|
|
|
|
|
I want to display popup menu when clicking inside richedit control.
How to get the notification message when right click on it.
|
|
|
|
|
See here[^]
You need to google first, if you have "It's urgent please" mentioned in your question.
 _AnShUmAn_
|
|
|
|
|
Try using Spy++ to find out. But I bet it's WM_CONTEXTMENU...
You might also have to subclass the edit control to get the message - there are many articles on codeproject that sublcass a poor-edit control, and some for rich-edit controls which may help.
Iain.
Modification: Anshuman gives you a very good link to an article. Pay attention to him! - Iain.
Codeproject MVP for C++, I can't believe it's for my lounge posts...
modified on Friday, January 16, 2009 8:22 AM
|
|
|
|
|
Check out this article[^]. It explains how to show a context when you right click on a button. Follow the same for your richedit too.
Regards,
Jijo.
_____________________________________________________
http://weseetips.com[ ^] Visual C++ tips and tricks. Updated daily.
|
|
|
|
|
hi all,
plz tell me how i can get the picture represeting the user account( which shows in logon screen and startmenu ) in windows xp.
Thanks & Regards
|
|
|
|
|
It seems that under C:\Documents and Settings\All Users\Application Data\Microsoft\User Account Pictures\ Windows XP stores an image with the user's login name that will be shown on the logon screen. So if your user's login name is "nitin3", then it will be C:\Documents and Settings\All Users\Application Data\Microsoft\User Account Pictures\nitin3.bmp. Don't know about other versions of windows. If you find out about any API to access this information, tell me. 
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
|
|
|
|
|
I have installed the Platform SDK Windows Server 2003 Family, February 2003.
And now i want to use library files and include files of the installed sdk for my VC6.0 project.
So to do this, i changed the reference of include and library files in my VC6.0 project.
I went to Tools->Options then in Directories Tab and there, i changed the path
of the Include Files and Library Files.
And then i built my project.
But it is giving linker errors.
So how do i integrate this platform sdk with my project in VC6.0
Please help me.
abc_123
|
|
|
|
|
sunnyram wrote: So how do i integrate this platform sdk with my project in VC6.0
run the following application under the startmenu.
"Startmenu->All Programs->Microsoft Platform SDK February 2003->Visual Studio Registration->Register PSDK Directories with Visual Studio"
|
|
|
|
|
first Thanks for u r reply.
I did this but still getting the same linker error.
fatal error LNK1112: module machine type IA64 conflicts with target machine X86.
abc_123
|
|
|
|
|
It might help if you showed us what linker errors you were getting?
|
|
|
|
|
first Thanks for u r reply.
i am getting following linker error and also some command line warnings.
fatal error LNK1112: module machine type IA64 conflicts with target machine X86.
and command line warnings like:
cl: Command line warning D4007: '/Gm' requires '/Zi' option ignored.
cl: Command line warning D4002: ignoring unknown option '/ZI'.
cl: Command line warning D4002: ignoring unknown option '/GZ'.
abc_123
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
