The code below throws a segmentation fault inside the .join() of the std::thread class. However, that is happen only I use cv::fastMalloc to allocate a data array. If I use the 'new' keyword or the std::malloc function no error happens.
I need understand why this error happens because in fact I need a cv::Mat that uses this function.
int main() {
uchar* data = (uchar*) cv::fastMalloc(640);
std::atomic<bool> running(true);
std::thread thread([&] () {
while(running) {
// I'll perform some process with data here
// for now, just to illustrate, I put thread to sleep
std::this_thread::sleep_for(std::chrono::milliseconds(100));
}
});
std::this_thread::sleep_for(std::chrono::seconds(1));
running = false;
// segfault is thrown here
thread.join();
cv::fastFree(data);
return 0;
}
The GDB callstack follows below
#0 00429B26 _pthread_cleanup_dest () (??:??)
#1 003E32A0 ?? () (??:??)
Does anyone know what might be happening? I really think it is too crazy :S.
Thanks.
I solved this issue reinstalling the opencv. Apparently the problem was the different versions of compilers that I had compiled the opencv and I'm using in this example.
For the record, I had compiled the opencv some time ago with a MinGW version that not support std::thread (I think 4.7.x).
Related
I have a multi threaded program where I forgot to use a mutex. Once, the program aborted with the following stack trace:
T abort
T __libc_message
t malloc_printerr
T free
T operator delete(void*)
W std::basic_string<char, std::char_traits<char>, std::allocator<char>>::~basic_string()`
I used the gnu c++ compiler 4.4.3 (on Ubuntu 10.04). Is it true, that this behaviour could be because of the usage of the string like the following example. In real it is much more complicated but I want to know if the following simple code could cause such an abort.
Thread which aborts when the destructor of the copy string is called:
void f()
{
std::string s = someglobalstring;
}
Thread which modifies string:
void g()
{
someglobalstring = newcontent;
}
Questions:
Are newer C++ implementations thread safe with reading and writing of std::string?
Is it expected that the destructor aborts here?
Strings are not thread safe. If you want to do this, use a std::mutex when accessing your string.
void g()
{
std::lock_guard<std::mutex> lock(m);
someglobalstring = newcontent;
}
Same for f, and define m (type std::mutex) with the string.
I am currently developing a small C++ program that uses a database connection.
It is a connection with a MySQL database through CPPCONN connector.
Cause
I am using multiple threads and therefor I have created the following methods:
void Database::startThread()
{
fDriver->threadInit();
}
void Database::stopThread()
{
fDriver->threadEnd();
}
void Database::connect(const string & host, const string & user, const string & password, const string & database)
{
fDriver = sql::mysql::get_driver_instance();
fConnection.reset(fDriver->connect((SQLString)host,(SQLString)user,(SQLString)password));
fConnection->setSchema((SQLString) database);
fStatement.reset(fConnection->createStatement());
fConnection->setClientOption("multi-queries","true");
fConnection->setClientOption("multi-statements","true");
}
The problem is that I encounter a segmentation fault at the fDriver->threadInit() call.
I can assure you that fDriver is properly instantiated at that point through the connect function.
(fDriver is not null either)
The crash
Unfortunately I cannot give much more useful information but this is GDB's backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4d66700 (LWP 16786)]
0x0000000000414547 in Database::startThread (this=Unhandled dwarf expression opcode 0xf3
#0 0x0000000000414547 in Database::startThread (this=Unhandled dwarf expression opcode 0xf3) at src/core/database.cpp:73
#1 0x0000000000405443 in Parser::Parser (this=0x7ffff4d659b8) at src/core/sv_parse.cpp:11
#2 0x000000000041e76d in MessageProcessor::MessageProcessor (this=0x7ffff4d659b0, serverStartTime=...) at src/server/messageProcessor.cpp:12
#3 0x000000000041bae8 in Server::__lambda1::operator() (__closure=0x62c740) at src/server/server.cpp:89
#4 0x00007ffff763f550 in execute_native_thread_routine () at ../../../../../libstdc++-v3/src/c++11/thread.cc:84
#5 0x00007ffff6edb851 in start_thread () from /lib64/libpthread.so.0
#6 0x00007ffff6c2994d in clone () from /lib64/libc.so.6
Remark
Now the weird part: this crash does not occur all the time !
Sometimes it works perfectly.
But it is of course extremely annoying if it doesn't.
CPPCONN version is 1.1.3 and we are using g++ version 4.8.1.
I hope someone can shed some light on this mystery !
Giriel
I struggled for hours with the same mysterious segmentation faults.
I found that adding mutex lock around get_driver_instance() solves the problem.
Here is a basic skeleton for a threaded function. This works for selecting from database, might not work for inserting or updating.
#include <mutex>
std::mutex mtx;
void test()
{
sql::Driver *driver;
sql::Connection *con;
try {
mtx.lock();
driver = get_driver_instance();
mtx.unlock();
driver->threadInit();
con = driver->connect(HOST, USER, PASS);
...
con->close();
driver->threadEnd();
} catch(...) { ... }
}
I am having some trouble using the pantheios logging library with boost::threads. It seems that if I use any pantheios logging before creating the thread, I will get a segfault.
For example, the following would work:
thread_ = new boost::thread(&foo);
pantheios::log(pantheios::debug, "Hello world");
But if the order of the statements are switched, a stack trace reveals that I crash on start_thread in boost.
pantheios::log(pantheios::debug, "Hello world");
thread_ = new boost::thread(&foo);
// SEGFAULT!
Any ideas?
EDIT: More context
int main()
{
pantheios::log(...);
MyClass myClass(/* some arguments, which are all literals */);
// Do some more work
return 0;
}
// MyClass constructor
MyClass::MyClass(/* args */)
: member1_(arg1)
, member2_(arg2)
{
thread_ = new boost::thread(&MyClass::workerLoop, this);
}
// Destructor
MyClass::~MyClass()
{
thread_->join();
delete thread_;
}
This will segfault at start_thread. Once again if I swap the two lines in main it will work without any problems.
Looks like I figured it out. I was linking to different versions of boost. My system had boost version 1.40, whereas I was also using a newer version of boost I downloaded, 1.49. Notable the boost thread I was linking was to the older version.
Once I made the links to boost consistent, everything worked as expected.
What possible reasons do you know for the situation, described in the title? Here's what my bt looks like:
#0 0x00a40089 in ?? ()
#1 0x09e3fac0 in ?? ()
#2 0x09e34f30 in ?? ()
#3 0xb7ef9074 in ?? ()
#4 0xb7ef9200 in ?? ()
#5 0xb7ef9028 in ?? ()
#6 0x081d45a0 in LogFile::Flush ()
#7 0x081d45a0 in LogFile::Flush ()
#8 0x081d46e0 in LogFile::Close ()
#9 0x081d4dbf in LogFile::OpenLogFile ()
#10 0x081d4eb9 in LogFile::PerformPeriodicalFlush ()
#11 0x081d4fca in LogFile::StoreRecord ()
#12 0x081d50c2 in LogFile::StoreRecord ()
and it gives me Program terminated with signal 11, Segmentation fault.
The wrapper around fflush() is simple, does nothing, just calls fflash and check for errors (if the returned code is <0 ). So, I guess the seg fault is caused by fflash. Or it's possible to be somewhere else, because of the ?? at the top of the stack?
OS: RHEL5; gcc version 3.4.6 20060404 (Red Hat 3.4.6-3); debugged with gdb, with the original exe with max debug information in it.
I know about seg fault on no space on the disk, but this is not this case (as I have a watch-dog for the application, that restarts the program again and everything keeps working just fine).
Any ideas would be helpful.
Thanks.
EDIT
void LogFile::PerformPeriodicalFlush( const utils::dt::TimeStamp& tsNow )
throw( LibCException )
{
m_tsLastPeriodicalCheck = tsNow;
struct stat LogFileStat;
int nResult = stat( m_sCurrentFullFileName.c_str(), &LogFileStat );
if ( 0 == nResult && S_ISREG( LogFileStat.st_mode ) )
{
//we successfuly stated the file, so it exists. We can safely perform
//a flush.
try
{
Flush();
return;
}
catch ( LibCException& )
{
OpenLogFile( tsNow );
return;
}
}
else
{
OpenLogFile( tsNow );
}
}
void RotatingLogFile::Flush() throw( object::LibCException )
{
if ( m_pFile != NULL )
{
if ( fflush( m_pFile ) (less_than) 0 )
{
throw object::LibCException();
}
}
}
**NOTE** can't paste the whole code, it's a part of 10+ thousands of code. Also this is working for years on different applications, on real-time systems. Such crashes are very, very rare - kinda twice a year. So, I don't think this is problem in the code. I know that noone can help me with this kind of stuff, that's why I'm just asking for any ideas, why fflush may cause seg fault.
My guess: you have memory corruption somewhere and LogFile's "this" points to a memory area that you can't access.
Anyway, it's difficult to tell without code.
It appeared, that for some reasons, there was something strange with the permissions (not sure what exactly), but this had happened on a hour change, as different files are written for each hour. So, In some way, the file was created, but there were no permissions to write in it, or something like this. No one actually understood what, why and how that happened(because after the crash, the application was restarted and everything was just perfectly fine). So, flush crashed, because of no permissions to do that.
It's still mystery .. but solved xD
You don't provide the code for Flush(), but sounds strange to me that it is called twice. In fact it seems that it calls itself. This may cause some resource leak, depending on the implementation of Flush().
Run your program under valgrind, it will help you find the source of where your application's memory is corrupted.
I am struggling with calling a clutter function from an extra thread.
I use boost::thread for threading and the clutter library 1.0.
To be specific, the thread contains a looped function that emits boost::signals2::signal with parameters of x and y coordinates every once in a while.
That signal is connected to a function that hands those variables to clutter, i.e. x,y in
clutter_stage_get_actor_at_pos(CLUTTER_STAGE(actor),
CLUTTER_PICK_ALL, x, y);
And that is where i get a segfault.
Apparently clutter has some thread-handling routines. I tried calling
g_thread_init(NULL);
clutter_threads_init();
before starting clutter_main(). I also tried enclosing the clutter function in
clutter_threads_enter();
clutter_stage_get_actor_at_pos(CLUTTER_STAGE(actor),
CLUTTER_PICK_ALL, x, y);
clutter_threads_leave();
but that does also not do the trick..
Every hint is appreciated, thank you in advance!
Addendum
I just forged a minimal sample of what I am trying to do. I already 'protected' the clutter_main() routine as suggested. Some functions of clutter seem to work (e.g setting stage color or setting actor position) from the seperate thread. Is there still something wrong with my code?
#include <clutter/clutter.h>
#include <boost/thread.hpp>
ClutterActor *stage;
ClutterActor* rect = NULL;
void receive_loop()
{
while(1)
{
sleep(1);
clutter_threads_enter();
ClutterActor* clicked = clutter_stage_get_actor_at_pos(CLUTTER_STAGE(stage), CLUTTER_PICK_ALL,300, 500);
clutter_threads_leave();
}
}
int main(int argc, char *argv[])
{
clutter_init(&argc, &argv);
g_thread_init(NULL);
clutter_threads_init();
stage = clutter_stage_get_default();
clutter_actor_set_size(stage, 800, 600);
rect = clutter_rectangle_new();
clutter_actor_set_size(rect, 256, 128);
clutter_actor_set_position(rect, 300, 500);
clutter_group_add (CLUTTER_GROUP (stage), rect);
clutter_actor_show(stage);
boost::thread thread = boost::thread(&receive_loop);
clutter_threads_enter();
clutter_main();
clutter_threads_leave();
return 0;
}
Well, I think I found the answer..
Clutter Docs Gerneral
It says in section "threading model":
The only safe and portable way to use the Clutter API in a multi-threaded environment is to never access the API from a thread that did not call clutter_init() and clutter_main().
The common pattern for using threads with Clutter is to use worker threads to perform blocking operations and then install idle or timeour sources with the result when the thread finished.
Clutter provides thread-aware variants of g_idle_add() and g_timeout_add() that acquire the Clutter lock before invoking the provided callback: clutter_threads_add_idle() and clutter_threads_add_timeout().
So my correction to the minimal sample code would be to alter the receive_loop() to
void receive_loop()
{
while(1)
{
sleep(1);
int pos[2];
pos[0] = 400;
pos[1] = 200;
clutter_threads_add_idle_full (G_PRIORITY_HIGH_IDLE,
get_actor,
&pos,
NULL);
}
}
and to add the get_actor function (as in the example code on the menitioned doc page)
static gboolean
get_actor (gpointer data)
{
int* pos = (int*) data;
ClutterActor* clicked = clutter_stage_get_actor_at_pos(CLUTTER_STAGE(stage), CLUTTER_PICK_ALL, pos[0], pos[1]);
return FALSE;
}
clutter_threads_add_idle_full takes care of thread lock etc..
I struggled with a very similar situation in the Python bindings for clutter. I was never able to make the Clutter thread support work the way I wanted.
What finally did the trick was using an idle proc (gobject.idle_add in python) to push the work I needed done into the main clutter thread. That way I have only 1 thread making clutter calls and everything is fine.
I played with your code and it seems you are doing everything ok, though I'm no expert in Clutter. I also ran your program under gdb and some interesting things showed up:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb799db70 (LWP 3023)]
0x002d97c6 in glDisable () from /usr/lib/nvidia-current/libGL.so.1
(gdb) thread apply all bt
Thread 2 (Thread 0xb799db70 (LWP 3023)):
#0 0x002d97c6 in glDisable () from /usr/lib/nvidia-current/libGL.so.1
#1 0x001b3ec3 in cogl_disable_fog () from /usr/lib/libclutter-glx-1.0.so.0
#2 0x0018b00a in ?? () from /usr/lib/libclutter-glx-1.0.so.0
#3 0x0019dc82 in clutter_stage_get_actor_at_pos () from /usr/lib/libclutter-glx-1.0.so.0
#4 0x080498de in receive_loop () at seg.cpp:19
Apparently the crash happened on glDisable () from /usr/lib/nvidia-current/libGL.so.1. Notice that I use NVIDIA's OpenGL driver on my GeForce 8600 GT.
Can you confirm that your application also crashes on computers with other video cards (not NVIDIA)? I doubt the crash is due to a bug on NVIDIA's OpenGL implementation.
For me it seems that *clutter_threads_enter/leave()* is not protecting *clutter_stage_get_actor_at_pos()* since I tested *receive_loop()* being called as a callback:
g_signal_connect(stage, "button-press-event", G_CALLBACK(receive_loop), NULL);
so we know that your code seems to be ok.
I encourage you to send your question to Clutter discussion and help mailing list: clutter-app-devel-list
a mailing list for application developers using Clutter, its integration libraries or toolkits based on Clutter.
You can either use clutter_threads_add_idle to update ClutterActor or you need to fix the clutter_threads_enter/leave to switch OpenGL context as well so that you can use it inside a thread.
The crash
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb799db70 (LWP 3023)]
0x002d97c6 in glDisable () from /usr/lib/nvidia-current/libGL.so.1
(gdb) thread apply all bt
Thread 2 (Thread 0xb799db70 (LWP 3023)):
#0 0x002d97c6 in glDisable () from /usr/lib/nvidia-current/libGL.so.1
#1 0x001b3ec3 in cogl_disable_fog () from /usr/lib/libclutter-glx-1.0.so.0
#2 0x0018b00a in ?? () from /usr/lib/libclutter-glx-1.0.so.0
#3 0x0019dc82 in clutter_stage_get_actor_at_pos () from /usr/lib/libclutter-glx-1.0.so.0
#4 0x080498de in receive_loop () at seg.cpp:19
is because the calling thread didn't acquire OpenGL context so it crashed.