|
If your are OK in your LIBs and their clients code,
you could control (for example by tracing) the symmetry
of new/delete and constructor/destructor calls...
...or use a tool (for example Bounce Checker) 
At the Debugging print all addresses of used modules (Break->Debug->Views->Modules)
to compare the ending output with them
and know the module(s) of the leak(s).
virtual void BeHappy() = 0;
|
|
|
|
|
You can start by using google[^]. This question has been asked and answered a few times.
|
|
|
|
|
Bound Checker!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
|
Hi all
How can i get blackberry IMEI Number?
Please help me.
|
|
|
|
|
Google!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
i use google but there havn't found any API and example then i ask here.
|
|
|
|
|
i guess on your BlackBerry u need to type this key combination
*#06#
this works on all branded ones - Nokia,LG,Samsung,Motorola,Siemens
|
|
|
|
|
Thanks but how can i retrieve through programing?
|
|
|
|
|
By picking one of the links and following directions?
I just hit google with this text: "c++ retrieve blackberry imei[^]"
Heavens knows what you'll find...
|
|
|
|
|
Hello everyone,
I would like to hook OleGetClipboard to return a custom IDataObject.
Injecting my code in the target application and hooking the function is quite easy and works pretty well. However, things get messy after the code of the function has been executed (app crash after a few seconds).
Here is the code of the MyOleGetClipboard function:
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
FORMATETC f = { CF_HDROP, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
STGMEDIUM s = { TYMED_HGLOBAL, { 0 }, 0 };
s.hGlobal = GetFileToPaste(); // Returns the handle to the DROPFILES structure (memory allocated with GlobalAlloc)
*ppDataObj = new MyDataObject(&f, &s, 1);
return (*ppDataObject) ? S_OK : E_OUTOFMEMORY;
}
The target application calls the methods from the returned object successfully, but I suspect some memory-related problem. For instance, the following code will also lead to a crash after a few seconds:
struct CFoo
{
CFoo()
{
m_i = new int[512];
}
~CFoo()
{
delete [] m_i;
}
int *m_i;
};
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
CFoo *f = new CFoo();
delete f;
return fpOleGetClipboard(ppDataObj); // Call the original implementation
}
Do you have any idea on how I should deal with this?
Any help or hint would be greatly appreciated.
Thank you!
|
|
|
|
|
Does it happen also if you do a small test app of your own and invoke your hooked procedure from that?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
No, it works fine when called from a test app of my own
|
|
|
|
|
I'm just guessing here too but try allocating/freeing memory differently, like using CoTaskMemAlloc[^] and CoTaskMemFree[^], or using the IMalloc[^]. IF you need constructors to run, then use placement new after allocating the memory, however, if your object also allocates things dynamically along the way, like your CFoo constructor does, you might need to modify that also. As said, i might be completely off the track here...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I overloaded the new and delete operators to use the functions you mentioned, but it does not solve the problem unfortunately.
void * MyDataObject::operator new(size_t n)
{
return CoTaskMemAlloc(n);
}
void MyDataObject::operator delete(void *p)
{
CoTaskMemFree(p);
}
I'm getting really puzzled.
|
|
|
|
|
And in your CFoo example, if you don't perform any new-delete, just call the original method, does it work?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Yes it does. It also works with MyDataObject as long as I do not return the pointer to the caller.
I've done some more tests and I'm completely lost:
// Works fine
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
return fpOleGetClipboard(ppDataObj); // Call the original function
}
// Will lead to a crash after a few seconds
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
*ppDataObj = NULL;
return fpOleGetClipboard(ppDataObj);
}
// Will lead to a crash after a few seconds
HRESULT MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
HRESULT hr = fpOleGetClipboard(ppDataObj);
OutputDebugString(L"After fpOleGetClipboard");
return hr;
}
|
|
|
|
|
Might be a calling-convention problem, try adding __stdcall or somesuch, am not sure by heart, like this:
HRESULT __stdcall MyOleGetClipboard(LPDATAOBJECT *ppDataObj)
{
...
}and see if it changes anything. Might try with __cdecl too if the __stdcall doesn't work.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
It's working! You're a genius.
The function declaration on MSDN is actually different from the declaration in the header files, calling convention has to be __stdcall (which makes sense as this is some COM related stuff)!
Thanks so much for your help!
|
|
|
|
|
Yourwelcome, i'm glad it worked out!
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Hi everyone, I would like to know if the header file <process.h> is a Windows header file or part of the ANSI standard. If it is Windows specific header, then how will I write an application that will create threads when portability is of much concern. Thanks in advance.
|
|
|
|
|
|
«_Superman_» wrote: It is a standard C header file
I guess you completely missed the following part of the Wikipedia article: "Neither the header file nor the functions are defined by either the ANSI/ISO C standard or by POSIX"
|
|
|
|
|
It's not a standard header, it tends to be Microsoft C and it's descendents and workalikes that implement it.
So if you want to create a portable threading application then get a portable library. Your options for this include:
- Use C++0x. Unfortunately a complete implementation of this on all the platforms you want us unlikely to be supported soon. VC++ 2010 for example doesn't have the threads library in it
- Use Boost - this is a good choice as it's largely upwards compatible with the upcoming C++ standard and is maintained by Anthony Williams one of the main test implementers of the new standard
- Use some other portable library, e.g. find something like pthreads for windows and use them on all your platforms. The problem is that pthreads is pretty low level - it's really one of the assembly languages of concurrent programming
Out of those I'd go with boost as the code you write today will probably work for the next 5 years and will be fairly easy to port to whatever C++0x compilers we've got then.
Cheers,
Ash
|
|
|
|
|
In addition to what Ash said, if you are going to write a widowed application and you want it to be cross-platform, you could have a look to some cross-platform GUI library; a very good one is the Qt[^]: it has lots of classes and functionalities for GUI programming and not only (threading, XML, scripting, etc.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
