global handler invokation - c++

I have overloaded new function but unfortunetly never been able to execute global handler for requesting more memory access on my compiler. I also don't understand as per below code snippet if we invoke the
global handler for requesting more memory how it is gling to allocate to P.
I appreciate if anybody can through some light on this
void * Pool:: operator new ( size_t size ) throw( const char *)
{
int n=0;
while(1)
{
void *p = malloc (100000000L);
if(p==0)
{
new_handler ghd= set_new_handler(0);//deinstall curent handler
set_new_handler(ghd);// install global handler for more memory access
if(ghd)
(*ghd)();
else
throw "out of memory exception";
}
else
{
return p;
}
}
}

To have any effect, some other part of the program must have installed a global handler previously. That handler must also have some kind of memory to release when the handler is called (perhaps some buffers or cache that can be discarded).
The default new_handler is just a null pointer, so your code is very likely to end up throwing an exception.
Also, I would have thrown a bad_alloc exception to be consistent with other operator new overloads.

Here are two things to discuss, the first is using new_handler, the second is overloading operator new.
set_new_handler()
When you want use a new_handler, you have to register it. It is typically the first thing to do after entering main(). The handler should also be provided by you.
#include <iostream>
#include <new>
void noMemory() throw()
{
std::cout << "no memory" << std::endl;
exit(-1);
}
int main()
{
set_new_handler(noMemory);
// this will probably fail and noMemory() will be called
char *c = new char[100000000L];
std::cout << "end" << std::endl;
}
When no memory can be allocated, your registered handler will be called, and you have the chance to free up some memory. When the handler returns, operator new will give another try to allocate the amount of memory you requested.
operator new
The structure of the default operator new is something similar you presented. From the point of the new_handler the important part is the while(1) loop, since it is responsible for trying to get memory after called the new_handler.
There is two way out of this while(1) loop:
getting a valid pointer
throwing an exception
You have to have this in mind when you provide a new_handler, because if you can not do anything to free up memory you should deinstall the handler (or terminating or throwing an exception), otherwise you can stuck in an endless loop.
I guess omitting parameter size in your code is just for test purpose.
Also see Scott Meyers' Effective C++ Item 7 for details. As operator new must return a valid pointer even with parameter size = 0, the first thing to do in your operator new should be overwriting size to 1 in case of the user want to allocate 0 number of bytes. This trick is simple and fairly effective.

Related

C++ / objective c thread call losing parameter

Our code has just started crashing due to a thread calling a memory alloc function and losing the pointer to the memory pool.
The pointer is initialised before the threads are started, but when the thread uses it to call the memory alloc code, it's zero.
In out init code we have
poolptr = InitMemoryPool ()
This sets it to a non zero memory address
In our .mm code on the thread we have
unsigned byte * p=(unsigned byte * ) MyAlloc ( poolptr, amount )
When the code gets into the MyAlloc function, poolptr is 0
Do I need my poolptr pointer to be volatile ? Even so, it's value is set up before the thread starts and never changes, so if the compiler is assuming it's a const, why doesn't it have it set correctly ?
Also, this has worked fine for years - and just started going wrong yesterday, simultaneously on two peoples machines.
Any ideas ?
This, what you mentioned, I don't do. What eventually worked for me is as follows:
I call my function or method and put in that function or method local instances of an class on the heap via command "new". Data that is to be returned is also paid respect to. Triggering a new thread will have access to that heap area if the heap area is a simple parameter. I.e., t= new thread( parameter);
void* function_or_method() {
clist *lstp;
string *_ps;
bool b;
try {
lstp= NULL;
lstp= new clist;
_ps= new string;
lstp->set( (void *)_ps);
mathclass *math;
thread *_thread;
math= new mathclass();
if((NULL==math))
throw Exception();
b= math->set( lstp);
if(! b) {
throw Exception();
}
_thread= new thread( math);
_thread->join();
delete _thread;
_thread= NULL;
} catch(const exception& e) {
clog <<"exception: logging" <<endl;
}
return (void*)lstp;
}
Okay, this is just C++ as well as C. I hope it will help a bit.

operator new, new_handler function in c++

This is pseudocode for the operator new:
while (true)
{
Attempt to allocate size bytes
if (the allocation was successful)
return (a pointer to the memory);
// The allocation was unsuccessful; find out what the
// current new-handling function is
new_handler globalHandler = set_new_handler(0);
set_new_handler(globalHandler);
if (globalHandler)
(*globalHandler)();
else
throw std::bad_alloc();
}
Questions :
1) Why first time 0 is passed as parametr to set_new_handler function?
2) It says that when allocation failed, new_handler function invoked, try to allocate momory and if and only if cant makes more memory, it return pointer to the start of allocated memory or if it cant, it throws bad_alloc exeption or returns null pointer and else body works, which throws a bad_alloc exeption.
My question is why new_handler function sometimes throws exeption, if it can return null pointer and else body would do this ?
1) Why first time 0 is passed as parametr to set_new_handler function?
According to docs this code:
new_handler globalHandler = set_new_handler(0);
set_new_handler(globalHandler);
will
(1) set up handler to null pointer (passed as a parameter)
(2) retrieve function pointer to current handler into globalHandler variable
(3) set up handler back to what it was (whatever globalHandler is pointing to now)
This is performed to retrieve a function pointer to the current handler.
when allocation failed, new_handler function invoked,
try to allocate momory
Unknown. I don't see where it allocates any memory here, as there is no code for it. User is free to do anything inside the new handler, but allocating memory is the last thing I would do. In fact, appropriate behavior would be to release some memory.
and if and only if cant makes more memory, it
return pointer to the start of allocated memory or if it cant, it throws bad_alloc exeption or returns null pointer
Wrong. new_handler does not return anything, it's a typedef to a function pointer accepting no parameters and returning void:
typedef void (*new_handler)();
and else body works, which throws a bad_alloc exeption
else block only works when there is no handler installed (it is null pointer), not when new_handler "fails" or throws an exception or whatever
Read it like this:
void* operator new (std::size_t size, optional blah blah here) blah blah here
{
while(true) // until universe exists (or a nearest power station)
{
// Try to allocate somehow
// Allocation failed
// Retrieved `global_handler` - a pointer to `void (*new_handler)` somehow
if (globalHandler) // global_handler is not null pointer?
{
(*globalHandler)(); // no, invoke it and loop again
}
else
{
throw std::bad_alloc(); // it's null, nothing to do, exception, sorry
}
}
}
See also:
How should I write ISO C++ Standard conformant custom new and delete operators?
This is pre-C++11 code, where the only way to get the current new handler is via the slightly hackish approach of calling set_new_handler to set a new one, which also happens to return the previous handler. Now we have get_new_handler so that we can avoid the set-the-handler-to-null-pointer-to-obtain-the-original-and-then-restore-the-value circumlocution.
In other words,
new_handler globalHandler = set_new_handler(0);
set_new_handler(globalHandler);
is a more convoluted (and more dangerous) way of writing
new_handler globalHandler = get_new_handler();
in C++11.
A new handler's return type is void - it doesn't return a pointer. Actually returning from a new handler (instead of throwing an exception or just terminating the program) essentially means "try again".

How does std::set_new_handler make more memory available?

From std::set_new_handler
The new-handler function is the function called by allocation functions whenever a memory allocation attempt fails. Its intended purpose is one of three things:
make more memory available
terminate the program (e.g. by calling std::terminate)
throw exception of type std::bad_alloc or derived from std::bad_alloc
Will the following overload gurantees anything ?
void * operator new(std::size_t size) throw(std::bad_alloc){
while(true) {
void* pMem = malloc(size);
if(pMem)
return pMem;
std::new_handler Handler = std::set_new_handler(0);
std::set_new_handler(Handler);
if(Handler)
(*Handler)();
else
throw bad_alloc();
}
}
std::set_new_handler doesn't make memory available, it sets a new-handler function to be used when allocation fails.
A user-defined new-handler function might be able to make more memory available, e.g. by clearing an in-memory cache, or destroying some objects that are no longer needed. The default new-handler does not do this, it's a null pointer, so failure to allocate memory just throws an exception, because the standard library cannot know what objects in your program might not be needed any more. If you write your own new handler you might be able to return some memory to the system based on your knowledge of the program and its requirements.
Here is a working example illustrating the functioning of custom new handlers.
#include <iostream>
#include <new>
/// buffer to be allocated after custom new handler has been installed
char* g_pSafetyBuffer = NULL;
/// exceptional one time release of a global reserve
void my_new_handler()
{
if (g_pSafetyBuffer) {
delete [] g_pSafetyBuffer;
g_pSafetyBuffer = NULL;
std::cout << "[Free some pre-allocated memory]";
return;
}
std::cout << "[No memory to free, throw bad_alloc]";
throw std::bad_alloc();
}
/// illustrates how a custom new handler may work
int main()
{
enum { MEM_CHUNK_SIZE = 1000*1000 }; // adjust according to your system
std::set_new_handler(my_new_handler);
g_pSafetyBuffer = new char[801*MEM_CHUNK_SIZE];
try {
while (true) {
std::cout << "Trying another new... ";
new char[200*MEM_CHUNK_SIZE];
std::cout << " ...succeeded.\n";
}
} catch (const std::bad_alloc& e) {
std::cout << " ...failed.\n";
}
return 0;
}
I do not suggest the demonstrated strategy for production code, it may be too heavy to predict, how many allocations will succeed after your new_handler is called once. I observed some successful allocations on my system (play with the numbers to see what happens on yours). Here's one possible output:
Trying another new... ...succeeded.
Trying another new... ...succeeded.
Trying another new... ...succeeded.
Trying another new... ...succeeded.
Trying another new... ...succeeded.
Trying another new... [Free some pre-allocated memory] ...succeeded.
Trying another new... ...succeeded.
Trying another new... ...succeeded.
Trying another new... ...succeeded.
Trying another new... [No memory to free, throw bad_alloc] ...failed.
Process returned 0 (0x0) execution time : 0.046 s
Press any key to continue.
Instead, from my perspective, do the release of a safety buffer only for terminating your program in a safe way. Even proper exception handling needs memory, if there isn't enough available, abort() is called (as I learned recently).

catching exception for memory allocation

void newHandler() {
cdebug << "memory allocation failure" << std::endl;
throw std::bad_alloc();
}
int main() {
std::set_new_handler(newHandler);
// ...
}
Once newHandler is established as our error handler, it will be called
when any heap allocation fails. The interesting thing about the error
handler is that it will be called continiously until the memory
allocation succeeds, or the function throws an error.
My question on above text is what does authore mean by " until the memory allocation succeeds, or the function throws an error." How can function can throw an error in this case? Request with example to understand.
Thanks for your time and help.
Basically, your handler may have 3 behavior
It throws a bad_alloc (or its derivate class).
It call exit or abord function which stop the program execution
It return, in which case a new allocation attempt will occur
refs: http://www.cplusplus.com/reference/new/set_new_handler/
This is helpful if you dont want to handle allocation error on each new call.
Depending on your system (using a lot of memory) you can for example free some allocated memory (cache), so the next try memory allocation can be successful.
void no_memory ()
{
if(cached_data.exist())
{
std::cout << "Free cache memory so the allocation can succeed!\n";
cached_data.remove();
}
else
{
std::cout << "Failed to allocate memory!\n";
std::exit (1); // Or throw an expection...
}
}
std::set_new_handler(no_memory);
The intent is that the handler can free some memory, return, and then new() can retry allocation. new() will call the handler as long as the allocation keeps failing. The handler can abort these attempts by throwing bad_alloc(), essentially saying 'I cannot free any more memory, so the allocation can't suceed'.
More details here:
http://www.cplusplus.com/reference/new/set_new_handler/

If a constructor throws exception, then does it make sense to have a global object of that class?

I am asking this question for general coding guidelines:
class A {
A() { ... throw 0; }
};
A obj; // <---global
int main()
{
}
If obj throws exception in above code then, it will eventually terminate the code before main() gets called. So my question is, what guideline I should take for such scenario ? Is it ok to declare global objects for such classes or not ? Should I always refrain myself from doing so, or is it a good tendency to catch the error in the beginning itself ?
If you NEED a global instance of an object whose constructor can throw, you could make the variable static, instead:
A * f(){
try {
//lock(mutex); -> as Praetorian points out
static A a;
//unlock(mutex);
return &a;
}
catch (...){
return NULL;
}
}
int main() {
A * a = f(); //f() can be called whenever you need to access the global
}
This would alleviate the problem caused by a premature exception.
EDIT: Of course, in this case the solution is 90% of the way to being a Singleton. Why not just fully turn it into one, by moving f() into A?
No, you should not declare such objects global - any exception will be unhandled and very hard to diagnose. The program will just crash which means that it will have very poor (below zero) user experience and will be rather hard to maintain.
As #Kerrek SB has mentioned in the comments, the answer to this is dependent on the reasons that can cause your class to throw. If you're trying to acquire a system resource that might be unavailable, I feel you shouldn't declare a global object. Your program will crash as soon as the user tries to run it; needless to say, that doesn't look very good. If it can throw a std::bad_alloc or some such exception that is unlikely under normal circumstances (assuming you're not trying to allocate a few GB of memory) you could make a global instance; however, I would still not do that.
Instead, you could declare a global pointer to the object, instantiate the object right at the beginning of main (before any threads have been spawned etc.) and point the pointer to this instance, then access it through the pointer. This gives your program a chance to handle exceptions, and maybe prompt the user to take some sort of remedial measures (like popping up a Retry button to try and reacquire the resource, for instance).
Declaring a global object is fine, but the design of your class is insignificant, it lacks details to be compatible with practical needs and use.
One solution no one seems to have mentionned is to use a function try
block. Basically, if the situation is that without the constructed
object, the rest of your program won't work or be able to do anything
useful, then the only real problem is that your user will get some sort
of incomprehensible error message if the constructor terminates with an
exception. So you wrap the constructor in a function try block, and
generate a comprehensible message, followed by an error return:
A::() try
: var1( initVar1 )
// ...
{
// Additional initialization code...
} catch ( std::exception const& ) {
std::cerr << "..." << std::endl;
exit(EXIT_FAILURE);
} catch (...) {
std::cerr << "Unknown error initializing A" << std::endl;
exit(EXIT_FAILURE);
}
This solution is really only appropriate, however, if all instances of
the object are declared statically, or if you can isolate a single
constructor for the static instances; for the non-static instances, it
is probably better to propagate the exception.
Like #J T have said, you can write like this:
struct S {
S() noexcept(false);
};
S &globalS() {
try {
static S s;
return s;
} catch (...) {
// Handle error, perhaps by logging it and gracefully terminating the application.
}
// Unreachable.
}
Such scenario is quite a problem, please read ERR58-CPP. Handle all exceptions thrown before main() begins executing for more detail.