Detecting QStack overflow
-
wrote on 13 Jul 2020, 19:13 last edited by
Not sure if you people get my idea.
It's not that I need more memory.
It's that I want to detect when there's no more available memory for my QStack, to stop the recursive calls at that point.
If QStack::push() returned a bool result, meaning allocation success or something alike, this would be easy.
-
@Alvein said in Detecting QStack overflow:
It's that I want to detect when there's no more available memory for my QStack, to stop the recursive calls at that point.
I would guess it's too late then but: https://en.cppreference.com/w/cpp/memory/new/bad_alloc
-
@Alvein said in Detecting QStack overflow:
It's that I want to detect when there's no more available memory for my QStack, to stop the recursive calls at that point.
I would guess it's too late then but: https://en.cppreference.com/w/cpp/memory/new/bad_alloc
wrote on 13 Jul 2020, 20:46 last edited byOK. Will try that. Thanks. :)
-
@Alvein said in Detecting QStack overflow:
It's that I want to detect when there's no more available memory for my QStack, to stop the recursive calls at that point.
I would guess it's too late then but: https://en.cppreference.com/w/cpp/memory/new/bad_alloc
wrote on 15 Jul 2020, 17:44 last edited by@Christian-Ehrlicher Hello. Tried std::bad_alloc but no exception is being thrown.
Can't find a clear way of enabling those (if something needs to be enabled, that is - because it shouldn't, by default, IMHO).
-
-
wrote on 16 Jul 2020, 06:35 last edited by
Thanks.
Finally, I implemented something like this...
template <class itemType> bool safePush(QStack<itemType> &stkStack,itemType stkItem) { bool bSP=true; try { stkStack.push(stkItem); } catch (std::bad_alloc) { bSP=false; } return bSP; }
...and it works now.
Not sure what was causing the exception ignoring, tho.
-
Thanks.
Finally, I implemented something like this...
template <class itemType> bool safePush(QStack<itemType> &stkStack,itemType stkItem) { bool bSP=true; try { stkStack.push(stkItem); } catch (std::bad_alloc) { bSP=false; } return bSP; }
...and it works now.
Not sure what was causing the exception ignoring, tho.
wrote on 16 Jul 2020, 09:39 last edited by@Alvein
Just to say: if you are so close to running out of memory that pushing one item to a stack causesstd::bad_alloc
, you may succeed in trapping the error and continuing as you have, but is it not likely that as you continue something else fails disastrously as there is no memory left to allocate? -
@Alvein
Just to say: if you are so close to running out of memory that pushing one item to a stack causesstd::bad_alloc
, you may succeed in trapping the error and continuing as you have, but is it not likely that as you continue something else fails disastrously as there is no memory left to allocate?wrote on 16 Jul 2020, 17:39 last edited by@JonB Not exactly sure if the "no memory" exception means no memory for a single continuous block. But I reckon I'm just being paranoid. I'm handling the stack myself since originally the call stack was not enough, so I just added the check because it looks good (and for learning something in the middle).
In the end, even if I catch the exception, that's not a dead end, since as it's coded, the process can be restarted from where it was, with an empty stack again.
TBH, by design, not even a restart is required because the process backtracks when the memory is full, freeing private stack space. I'll have to see it running live. But the probability of seeing it reaching the exception is terribly low.
-
@JonB Not exactly sure if the "no memory" exception means no memory for a single continuous block. But I reckon I'm just being paranoid. I'm handling the stack myself since originally the call stack was not enough, so I just added the check because it looks good (and for learning something in the middle).
In the end, even if I catch the exception, that's not a dead end, since as it's coded, the process can be restarted from where it was, with an empty stack again.
TBH, by design, not even a restart is required because the process backtracks when the memory is full, freeing private stack space. I'll have to see it running live. But the probability of seeing it reaching the exception is terribly low.
wrote on 16 Jul 2020, 17:51 last edited bybecause the process backtracks when the memory is full, freeing private stack space
Again, just an observation :) I think you might be being too optimistic! You seem to assume two things:
-
Freed blocks will get re-used, at this point, for another allocation. May depend on whether it's an odd or even day of the week ;)
-
The code executed for backtracking does not itself do any allocation, which might fail where you are. There are a lot of things you might call without realizing they do some allocation!
Best of luck.
-
-
because the process backtracks when the memory is full, freeing private stack space
Again, just an observation :) I think you might be being too optimistic! You seem to assume two things:
-
Freed blocks will get re-used, at this point, for another allocation. May depend on whether it's an odd or even day of the week ;)
-
The code executed for backtracking does not itself do any allocation, which might fail where you are. There are a lot of things you might call without realizing they do some allocation!
Best of luck.
wrote on 16 Jul 2020, 20:13 last edited byThank you very much for your advice.
- Freed blocks will get re-used, at this point, for another allocation. May depend on whether it's an odd or even day of the week ;)
Yes, I'm aware of that. My intention was simply avoiding my program to crash and tell the users what's happening, letting them to stop the process if they wish.
- The code executed for backtracking does not itself do any allocation, which might fail where you are. There are a lot of things you might call without realizing they do some allocation!
Backtracking, for me, means just popping out items from the private stack. Remember this is about simulating recursion, so such backtracking is also simulated. In the end, there's two options for the program, either using the recently freed memory, or behaving like if there was no more, in case that memory was immediately seized by other things. Each option has been considered and handled by code.
-
15/15