Retrieving the object info due to exception std::bad_alloc in Qt 4.8
-
@ambershark said in Retrieving the object info due to exception std::bad_alloc in Qt 4.8:
Are you running a low memory or embedded application that has RAM issues or something
Yes am running a low memory or embedded application that has RAM issues. I would like to catch all the exceptions including std::bad_alloc like below:-
try {
uiApp->exec();
}
catch (const std::exception& e)
{
Q_UNUSED(e);
qDebug()<< e.what();}But not able to get the object runtime info like class and method name which had thrown exception.
-
@ambershark said in Retrieving the object info due to exception std::bad_alloc in Qt 4.8:
Are you running a low memory or embedded application that has RAM issues or something
Yes am running a low memory or embedded application that has RAM issues. I would like to catch all the exceptions including std::bad_alloc like below:-
try {
uiApp->exec();
}
catch (const std::exception& e)
{
Q_UNUSED(e);
qDebug()<< e.what();}But not able to get the object runtime info like class and method name which had thrown exception.
@Ramakanth I don't know of a way for you to get the information with an std exception.
You could get it if you let the application crash in a debugger and did a backtrace. However while it is running and that is the only exception you get, then
.what()is the best you're going to get.You could try creating custom
newanddeleteoperators that log the information but that really does seem like overkill. -
@Ramakanth I don't know of a way for you to get the information with an std exception.
You could get it if you let the application crash in a debugger and did a backtrace. However while it is running and that is the only exception you get, then
.what()is the best you're going to get.You could try creating custom
newanddeleteoperators that log the information but that really does seem like overkill.@ambershark said in Retrieving the object info due to exception std::bad_alloc in Qt 4.8:
You could try creating custom new and delete operators that log the information but that really does seem like overkill.
Do you mean overloading the custom new and delete operators in a custom class and inherit the custom class across the application?
-
@ambershark said in Retrieving the object info due to exception std::bad_alloc in Qt 4.8:
You could try creating custom new and delete operators that log the information but that really does seem like overkill.
Do you mean overloading the custom new and delete operators in a custom class and inherit the custom class across the application?
-
@Ramakanth I don't know of a way for you to get the information with an std exception.
You could get it if you let the application crash in a debugger and did a backtrace. However while it is running and that is the only exception you get, then
.what()is the best you're going to get.You could try creating custom
newanddeleteoperators that log the information but that really does seem like overkill.You could try creating custom new and delete operators that log the information but that really does seem like overkill.
@ambershark Any reasons why it would be overkill? Whether it is not recommended or best practice? -
You could try creating custom new and delete operators that log the information but that really does seem like overkill.
@ambershark Any reasons why it would be overkill? Whether it is not recommended or best practice?@Ramakanth Well because every single new/delete will have extra work to do. Which means more cpu cycles. That directly slows your application down.
As for the overkill part, managing memory to this level is not needed in most applications. Only if you are writing a critical system like for an airplane or a hospital or something like that would you need to worry about this level of exception.
Like I said before if you can't allocate memory and it throws that exception your system is already in a non-responsive state. You would be far into virtual memory and everything would be crawling. It would feel locked up.
I've written millions of lines of code and many commercial products, and even some fairly critical systems on embedded devices. Never once needed to worry about catching that exception. By the time your system is out of memory it's pretty much dead anyway. :)
-
@ambershark said in Retrieving the object info due to exception std::bad_alloc in Qt 4.8:
Are you running a low memory or embedded application that has RAM issues or something
Yes am running a low memory or embedded application that has RAM issues. I would like to catch all the exceptions including std::bad_alloc like below:-
try {
uiApp->exec();
}
catch (const std::exception& e)
{
Q_UNUSED(e);
qDebug()<< e.what();}But not able to get the object runtime info like class and method name which had thrown exception.
@Ramakanth said in Retrieving the object info due to exception std::bad_alloc in Qt 4.8:
Yes am running a low memory or embedded application that has RAM issues.
As others have said, by the time you get down to one
newfalling over you're passed the point where you can recover properly. However, if this memory is an issue, what you could (maybe should) do is perform your own check for "plenty of remaining memory" intermittently or at a "safe" point of code, well before you get to no memory left at all. I don't know what the call is for that (perhaps native, not a Qt one), but I imagine there should be some way of detecting that you're getting "low" on remaining VM and deal with it then. Not perfect/scientific, but might be what you need. -
You could even take it a step further and do your own memory pool. That way you have a preallocated block reserved for your application and when/if it runs out it isn't when the system is dying from lack of RAM.
I don't know what you're working on, but this is usually overkill for 99% of apps out there.
I've done it before, just to learn back in my beginning c++ days. That was back in the 16 bit world where memory really was an issue. Your common PC back then had 64MB RAM if you were cool. ;)
My L-GPL'd C++ Logger github.com/ambershark-mike/sharklog
-
You could even take it a step further and do your own memory pool. That way you have a preallocated block reserved for your application and when/if it runs out it isn't when the system is dying from lack of RAM.
I don't know what you're working on, but this is usually overkill for 99% of apps out there.
I've done it before, just to learn back in my beginning c++ days. That was back in the 16 bit world where memory really was an issue. Your common PC back then had 64MB RAM if you were cool. ;)
I've done it before, just to learn back in my beginning c++ days. That was back in the 16 bit world where memory really was an issue. Your common PC back then had 64MB RAM if you were cool. ;)
64MB? Don't you mean 640K?? Actually that might have been C days, not C++.
Stop showing off how young you are ;-) In my beginning days, that was back in 8-bit world, where memory was really, really an issue. Your common Sinclair ZX-81 then had 1K RAM, though you could expand that to 16K (dongle on the back, but it tended to fall out as it was too heavy for the slot) if you were cool... ;)
-
I've done it before, just to learn back in my beginning c++ days. That was back in the 16 bit world where memory really was an issue. Your common PC back then had 64MB RAM if you were cool. ;)
64MB? Don't you mean 640K?? Actually that might have been C days, not C++.
Stop showing off how young you are ;-) In my beginning days, that was back in 8-bit world, where memory was really, really an issue. Your common Sinclair ZX-81 then had 1K RAM, though you could expand that to 16K (dongle on the back, but it tended to fall out as it was too heavy for the slot) if you were cool... ;)
@JonB Lol ... my very first computer was an Apple ][+ with 48K of RAM. That was when I was about 8. It was definitely 8 bit back then. But I didn't learn C++ until late high school/early college so yea 64MB was all sorts of cool at that time.
Although I knew about the sinclairs I never actually saw one since they were "outdated" by the apples.
