|
Doesn't work in the Swedish or German version... otherwise totally agree. 
|
|
|
|
|
WOW! that's news to me. Why so, is it a bug or does 'L' map to something else?!
PS: Searching the web was a chore so I am asking you.
|
|
|
|
|
Alt+L works because of the button text in the English dialog window (underlined letter L), right? My first guess is that it's not a keyboard accelerator and depends on internationalisation (different button text often means different key combination to activate that button).
|
|
|
|
|
Hi all..
i had made a exe with all shortcuts to system accessories and also editboxes to keep note of all priority things. It also displays the time elapsed from the system turn on time. If I check the Memory usage for this exe its drastically increasing.. Iam displaying the Hour:Minute:Second.. For each updation of these its consuming lot of memory. Plz help me to solve this.. I use this exe as part of my day to day work.
Thanks in advance.
|
|
|
|
|
You probably have some memory leak. Make sure that each memory allocated with new is deallocated with delete. Make also sure that you release all resources loaded on the update.
It's a bit difficult to give more detailed information since you didn't provide any code.
|
|
|
|
|
The first thing to do is look for everywhere you use "new." Wherever you find these places see if you can change the object to an automatic/stack based object OR immediately assign the result of the new to a management object (something like std::shared_ptr or boost::shared_ptr).
If that doesn't work have a look at libraries you're using and understand how objects in that library work. So if you're using MFC understand why and how CWnd objects handle self deletion in PostNCDestroy. If you're using OpenSSL make sure (by automating it) that all your BIO objects are closed properly. And so on with other libraries...
The point here is that if you don't do any manual memory management you can't leak any memory. Manual memory management can take many forms (e.g. using a vector as a stack and not clearing popped entries) so it's not necessarily just looking for "new" but it's a good start.
Cheers,
Ash
PS: Just thought - if you're using lower level raw memory management stuff like malloc/free( from the C standard library), HeapAlloc/HeapFree (from the windows API) or even VirtualAlloc(also from the windows API) make sure you're balancing allocations with freeing using management objects.
So my zeroth bit of advice should have been "don't use any object management apart from new/delete in C++ unless you have a very good reason not to." Once you've done that you can start removing news from your code.
modified on Thursday, October 7, 2010 7:22 AM
|
|
|
|
|
hii.. thanks a lot for that immediate response...
iam sharing few lines of code related to Editbox and Timer.. "New" is used in my code in OnCtlColor()..
please have a look in those.. If u are able to figure out with this ,where the problem is, plz do tell me...
BOOL CNoteDlg::OnInitDialog()
{
SetTimer(ID_CLOCK_TIMER,1000,NULL);
m_edit1.SetLimitText(10000);
m_edit1.SetWindowText("");
}
HBRUSH CNoteDlg::OnCtlColor(CDC* pDC, CWnd* pWnd, UINT nCtlColor)
{
if(pWnd->GetDlgCtrlID() == IDC_EDIT1)
{
pDC->SetTextColor(RGB(255, 0, 0));
pDC->SetBkColor(RGB(255, 255, 255));
brush = new CBrush(RGB(255,255,255));
}
}
void CNoteDlg::OnTimer(UINT nIDEvent)
{
DWORD totalseconds = 0, dwSec = 0, dwMin = 0;
if(GetUpTime(totalseconds))
{
dwSec = totalseconds % 60;
dwMin = totalseconds / 60;
}
DisplayUpTime(dwMin, dwSec);
}
void CNoteDlg::DisplayUpTime(const DWORD& dwMin,const DWORD& dwSec)
{
m_sbegin.Format("%d hours : %d minutes : %d seconds",(dwMin/60)%24, dwMin%60,dwSec);
GetDlgItem(IDC_BEGIN)->SetWindowText(m_sbegin);
}
Thanks again...
|
|
|
|
|
Greetings!
Our application is built in MS Visual C++ 6. I'm running Windows XP Pro, and our customer is running Windows Server 2003.
Our customer has reported rare instances in which our program has crashed, but the only way he knows about it is entries that appeared in the Windows System event log, as copies of the popup window that was displayed to the user. The source of the log entry is given as "Application Popup". The instruction address in one of the messages is 0x075c0001.
We do not currently have map files for our application. I thought that we should, and I started experimenting with them. For my first experiment, I forced a divide by zero error in the application's main executable, and rebuilt it with the correct settings to generate a map file. My application duly crashed, and shortly thereafter a popup message appeared telling me that an instruction at address 0x5f801088 referenced memory at 0x00000004. In my applicaton event log, I found an event reporting that my application faulted in its executable file, at address 0x0001fb3a. Using instructions I found on the Web, I was able to use the map file to go from address 0x0001fb3a to the correct line in my code. There was a second entry in the Windows event log, this time in the system log, repeating what the popup had told me.
I then repeated the experiment with one of the DLLs our application uses, and again I was successful, using the address found in the entry in the Windows application log. There was one difference here, though: I did not get the popup complaining about an instruction that failed, and I did not get an entry in the system log.
On our customer's system, the situation is the opposite: We have entries in the system log, but not in the application log.
The addresses of instructions given in the map file are all relatively low, low enough to contain the address given in the application event log, 0x0001fb3a. I cannot be positive that the address given in the popup message and the system log is referring to the same instruction, since it is quite possible that something else in the application is trying to use an object that just crashed and burned. But the high address number leads me to believe that it is using a different reference point. Maybe it is based on the raw address in the processor instead of the application's address space, or some such thing.
Can anyone give a theory about why our customer might see an error in the system log reporting a bad instruction, but no corresponding error in the application log? Can anyone point me to instructions on how to map the address in the system log to an entry in a map file?
Thank you very much!
RobR
|
|
|
|
|
Forget map files. Change the compiler and linker settings so that debug information (a .pdb file) is generated for the release version in addition to the debug version. From memory, in MSVC6 the steps are something like this:
- Go the project settings.
- Select the "Release" configuration.
- In the project settings on the "C++" tab choose "Debug" from the "Category" combo.
- Select the option to generate debug information (choose the option that doesn't include "Edit and Continue", that's used in the release build).
- Select the "Link" tab.
- Choose "Debug" from the "Category" combo.
- Select generate debug information (.pdb) and make sure "Separate Types" is NOT ticked (as it causes problems).
Now when you build keep the generated .pdb file (or user Microsoft's Symbol Server[^] to keep them for you), it's like a map file except useful. Using map files is common but misguided advice. You can use WinDBG[^] to extract information from the .pdb file or, more to the point, to process a crash dump file from your clients or that you get from Windows Error Reporting[^]
Steve
|
|
|
|
|
I need to convert packed RGB bitmap data into RGBQUAD format.
I like to use two buffers to manupulate the data.
The required buffer size is over 1 MB and the memcpy fails to copy data between buffers.
It works fine with 640*480*3 buffer size, but fails with 640*480*4.
I am using VC++ 6.0 on Windows 2000.
Any constructive suggestions to solve this problem in my development enviroment will be as always appreciated.
Thanks for reading.
Vaclav
SOLUTIONs
1. Watch the syntax for buffer allocation
2. Make sure the buffers are same size.
modified on Wednesday, October 6, 2010 5:17 PM
|
|
|
|
|
Vaclav_Sal wrote: It works fine with 640*480*3 buffer size, but fails with 640*480*4.
Stack or heap-based buffer?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thanks for quick reply.
I tryed these two methods,I am not sure they are stack or heap based.
I read the documentation and it is not too clear for me what is really used for storage / memeory allocation.
But they both fail .
iClipboardSize += iClipboardSize/3;
// allocate buffer space
LPBYTE lpBuffer;
lpBuffer = (LPBYTE) new BYTE[sizeof(iClipboardSize)];
ASSERT(lpBuffer);
lpBuffer = (LPBYTE)GlobalAlloc(GPTR,iClipboardSize);
ASSERT(lpBuffer);
// test copy data from clipboard to buffer
memcpy(lpBuffer,lpBI,iClipboardSize);
|
|
|
|
|
They are both heap-based memory allocation.
Vaclav_Sal wrote: lpBuffer = (LPBYTE) new BYTE[sizeof(iClipboardSize)];
This is not right. You are allocating 4 bytes of memory, yet the call to memcpy() is copying iClipboardSize bytes (which is likely far more than 4).
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
David,
sorry, I did not included the whole code.
The clipboard size is 640*480*3 + 40.
If the are both heap based why does the method using new fails with this clipboard size?
I think I'll try to build a new DIB bitmap instead of monkeying around whit this packed RGB AVI format. Mainly because I cannot figure out if the RGBQUAD is sized properly and if not how to resize it in BITMAPINFO structure.
Thanks for your help.
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: If the are both heap based why does the method using new fails with this clipboard size?
Because you are only allocating 4 bytes of memory.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Good spot.
|
|
|
|
|
Serves as a good example, what is the difference of arrays and pointers (and variables)... just recently had that topic. Good spot.
|
|
|
|
|
Good spot, but this discussion also serves as a shinning example on how to change the subject without arousing much suspicion.
I still cannot memcpy 640*480*4 size of buffer!
Thanks anyway. I am working on an alternative.
Vaclav
|
|
|
|
|
Vaclav_Sal wrote: I still cannot memcpy 640*480*4 size of buffer!
Have you tried:
lpBuffer = new BYTE[iClipboardSize];
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I like rhetorical questions. 
|
|
|
|
|
There are days I really like this forum.
|
|
|
|
|
Vaclav_Sal wrote: I still cannot memcpy 640*480*4 size of buffer!
I just tried
int size = 640*480*4;
PBYTE buffa = new BYTE[size];
PBYTE buffb = new BYTE[size];
memcpy(buffb, buffa, size);
and it works fine; total bytes copied 1,228,800.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
of course that works fine, there wasn't any real information in the source buffer!
|
|
|
|
|
And it fails if the destination buffer is smaller than the source buffer.
Thanks for all your inputs - problem solved.
|
|
|
|
|
Vaclav_Sal wrote: And it fails if the destination buffer is smaller than the source buffer.
Who'd a thunk it? 
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
