I'm trying to write a custom allocator to get better code coverage for branches that are executed only when OOM occurs. I managed to write the allocator, but when a bad_alloc is thrown on debug inside a class from std, an internal call to abort is made. This behavior is only on debug, on release I can run the tests.
Is there any way to disable this behavior on debug configuration?
Update #1
This is a code snippet where the problem described above occurs. I also forgot to mention that I use MSVC.
#include <iostream>
#include <string>
bool throw_bad_alloc = false;
void* operator new(size_t size)
{
if (throw_bad_alloc)
throw std::bad_alloc();
return ::malloc(size);
}
void operator delete(void* ptr)
{
::free(ptr);
}
int main()
{
try {
throw_bad_alloc = true;
std::string name;
name = "test_string";
}
catch (...)
{
std::cout << "thrown";
return 0;
}
std::cout << "not thrown";
return 0;
}
Related
I'm using the target attribute to generate different function implementations depending on the CPU architecture. If one of the functions throws an exception it doesn't get caught if I compile with gcc, but with clang it works as expected.
If there is only a single implementation of the function it does work for gcc as well.
Is this a bug in gcc?
Example (godbolt):
#include <stdexcept>
#include <iostream>
using namespace std;
__attribute__((target("default")))
void f() {
throw 1;
}
__attribute__((target("sse4.2,bmi")))
void f() {
throw 2;
}
int main()
{
try {
f();
}
catch(... )
{
std::cout << "Caught exception" << std::endl;
}
}
Output of gcc:
terminate called after throwing an instance of 'int'
Output of clang:
Caught exception
I reported this and a GCC developer confirmed it as a bug: link
For now a workaround seems to wrap the function and use the gnu::noipa attribute to disable interprocedural optimizations:
__attribute__((target("default")))
void f() {
throw 1;
}
__attribute__((target("sse4.2")))
void f() {
throw 2;
}
[[gnu::noipa]]
void f1()
{
f();
}
int main()
{
try {
f1();
}
catch(... )
{
return 0;
}
return 1;
}
The bug is now fixed in gcc's master branch and should be released with gcc version 13.
#include <iostream>
#include <sstream>
using std::string;
using std::cout;
using std::endl;
using std::ostringstream;
class illegalParameterValue {
private:
string message;
public:
illegalParameterValue() : message("Illegal parameter value") {}
explicit illegalParameterValue(const char* theMessage) {message = theMessage;}
void outputMessage() {cout << message << endl;}
};
int main() {
ostringstream s;
s << "index = " << 1 << " size = " << 2;
throw illegalParameterValue(s.str().c_str());
return 0;
}
I just use some code like this, but the throw will remind some warnings which called
Clang-Tidy: Throwing an exception whose type 'illegalParameterValue' is not derived from 'std::exception'
How can I solve this problem?
consider the following code:
try {
// do something that might throw an exception
}
catch (const std::exception &ex) {
// handle the exception
}
If you derive your illegalParameterValue class from std::exception, then the catch clause above will catch it (along with other kinds of exceptions derived from std::exception). As currently written, it will not. Your users will have to add another catch clause:
try {
// do something that might throw an exception
}
catch (const std::exception &ex) {
// handle std exceptions
}
catch (const illegalParameterValue &ip) {
// handle illegal parameter exeception
}
Maybe that's what you want, maybe not.
But there's a lot of code out there like the first case.
Suppose you have some external synchronous code you cannot modify, and you require it to run async but also require it to be cancellable. If the external code is blocking then I have two options.
A) Fool the user and let my async method return immediately on cancellation, well aware that the code is still running to completion somewhere.
B) Cancel execution
I would like to implement an interface for option B
namespace externallib {
std::uint64_t timeconsuming_operation()
{
std::uint64_t count = 0;
for (auto i = 0; i < 1E+10; ++i)
{
count++;
}
return count;
}
}
template <typename R>
struct async_operation
{
struct CancelledOperationException
{
std::string what() const
{
return what_;
}
private:
std::string what_{ "Operation was cancelled." };
};
template<typename Callable>
async_operation(Callable&& c)
{
t_ = std::thread([this, c]()
{
promise_.set_value(c()); // <-- Does not care about cancel(), mostly because c() hasn't finished..
});
}
std::future<R> get()
{
return promise_.get_future();
}
void cancel()
{
promise_.set_exception(std::make_exception_ptr(CancelledOperationException()));
}
~async_operation()
{
if (t_.joinable())
t_.join();
}
private:
std::thread t_;
std::promise<R> promise_;
};
void foo()
{
async_operation<std::uint64_t> op([]()
{
return externallib::timeconsuming_operation();
});
using namespace std::chrono_literals;
std::this_thread::sleep_for(5s);
op.cancel();
op.get();
}
In the code above I cannot wrap my head around the limitation of external code being blocking, how, if at all, is it possible to cancel execution early?
Short answer:
Don't cancel/terminate thread execution unless it is mission critical. Use approach "A" instead.
Long answer:
As #Caleth noted, there is no standard nor cross platform way to do this. All you can do is to get a native handle to a thread and use platform specific function. But there are some important pit falls.
win32
You may terminate a thread with TerminateThread function, but:
stack variables will not be destructed
thread_local variables will not be destructed
DLLs will not be notified
MSDN says:
TerminateThread is a dangerous function that should only be used in
the most extreme cases.
pthread
Here situation is slightly better. You have a chance to free your resources when pthread_cancel is got called, but:
By default, target thread terminates on cancellation points. It means that you cannot cancel a code that doesn't have any cancellation point. Basically, for(;;); won't be canceled at all.
Once cancellation point is reached, implementation specific exception is thrown, so resources can be gracefully freed.
Keep in mind, that this exception can be caught by try/catch, but it's required to be re-thrown.
This behavior can be disabled by pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, nullptr);. But in case cancellation point is not met, resources won't be freed (as for win32)
Example
#include <iostream>
#include <thread>
#include <chrono>
#if defined(_WIN32)
#include <Windows.h>
void kill_thread(HANDLE thread) {
TerminateThread(thread, 0);
}
#else
#include <pthread.h>
void kill_thread(pthread_t thread) {
pthread_cancel(thread);
}
#endif
class my_class {
public:
my_class() { std::cout << "my_class::my_class()" << std::endl; }
~my_class() { std::cout << "my_class::~my_class()" << std::endl; }
};
void cpu_intensive_func() {
#if !defined(_WIN32)
pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, nullptr);
#endif
my_class cls;
for(;;) {}
}
void io_func() {
my_class cls;
int a;
std::cin >> a;
}
void io_func_with_try_catch() {
my_class cls;
try {
int a;
std::cin >> a;
} catch(...) {
std::cout << "exception caught!" << std::endl;
throw;
}
}
void test_cancel(void (*thread_fn) (void)) {
std::thread t(thread_fn);
std::this_thread::sleep_for(std::chrono::seconds(1));
kill_thread(t.native_handle());
t.join();
std::cout << "thread exited" << std::endl;
std::cout << "--------------------" << std::endl;
}
int main() {
test_cancel(cpu_intensive_func);
test_cancel(io_func);
test_cancel(io_func_with_try_catch);
return 0;
}
You may see that:
The destructor is never called on windows.
Removing of pthread_setcanceltype leads to hang.
The internal pthread exception could be caught.
There is no portable way to end a thread before it wants to.
Depending on your platform, there may be ways of ending a thread, which you will probably need to get std::thread::native_handle to utilise. This is highly likely to lead to undefined behaviour, so I don't recommend it.
You can run that external synchronous code in another process and terminate that entire process. This way the interruption won't affect your process and cause undefined behaviour.
I am new to writing exceptions in c++ and I am struggling with an error. I won't get very much into detail 'cause I don't think this is relevant for the problem that I have.
#ifndef _STUDENT_H_
#define _STUDENT_H_
#include <string>
#include <map>
#include <vector>
#include <stdexcept>
#include <iostream>
class NoMarkException: public exception
{
public: NoMarkException():exception(){
cout<< "No marks were found." << endl;
}/*
NoMarkException(const string &name){
cout << "No marks for " << name << " were found."<< endl;
}*/
};
#endif
This is my NoMarkException class
float Student::getMaxMark() const throw(NoMarkException) {
if (marks.empty()) {
throw NoMarkException::NoMarkException();
}
float final = 0;
for (it = marks.begin(); it != marks.end(); it++) {
if ((*it).second > final) {
final = (*it).second;
}
}
return final;
}
And this is my Student.cpp
When I am building the project I get error: cannot call constructor 'NoMarkException::NoMarkException' directly
Any ideas why it is causing the problem?
if (marks.empty()) {
throw NoMarkException();
}
The error you get does not actually have anything to do with the fact you're using an exception class. The problem is that you're trying to instantiate an object of class NoMarkException by explicitly calling the (default) constructor, NoMarkException::NoMarkException(). In C++ you don't call constructors explicitly; rather, when you define a new variable, an appropriate constructor gets called. For example
void foo() {
std::vector<int> v(5);
NoMarkException my_exception();
NoMarkException my_other_exception();
}
or, using equivalent but more appropriate due to recent language changes:
void foo() {
std::vector<int> v { 5 };
NoMarkException my_exception { };
NoMarkException my_other_exception { };
}
In this case (both syntax alternatives), the constructors:
std::vector<int>::vector(std::vector<int>::size_type count)
NoMarkException::NoMarkException()
NoMarkException::NoMarkException()
are called (*).
In your case, you simply need to replace the explicit call you make to NoMarkException::NoMarkException() in the throw with an instantiation of NoMarkException object, i.e. your statement will be:
throw NoMarkException();
(*) - actually, the vector constructor that's called has a few more parameters which take their default values. See here.
I'm having trouble for a while with error C2712: Cannot use __try in functions that require object unwinding, after narrowing the problem, I was left with a very very simple code, and i can not understand why it causes this error. I am using Visual Studio under windows.
I am compiling with /EHa (I do not use /EHsc)
The reason I use __try/__except and not try/catch is because I want to catch ALL the errors, and do not want the program to crash under any circumstances, including for example division by 0, that try-catch does not catch.
#include <string>
static struct myStruct
{
static std::string foo() {return "abc";}
};
int main ()
{
myStruct::foo();
__try
{ }
__except (true)
{ }
return 0;
}
output:
error C2712: Cannot use __try in functions that require object unwinding
Here is the solution. For more details read Compiler Error C2712
#include <string>
struct myStruct
{
static std::string foo() {return "abc";}
};
void koo()
{
__try
{ }
__except (true)
{ }
}
int main ()
{
myStruct::foo();
koo();
return 0;
}
Extra Note: no need static if no declaration using your struct (myStruct).