Re: [devel] [PATCH 1/1] base: Destructor of TraceLog causes coredump V2 [#2860]

2018-05-24 Thread Minh Hon Chau
Hi Hans, Place it on heap so destructor won't be called as part of __do_global_dtor_aux I guess, it should be equivalent to the previous of TraceLog regarding this issue. I think you can make "if (mutex_ && mutext_->good())", it can pass the check mutex_ against null but not sure after

Re: [devel] [PATCH 1/1] base: Destructor of TraceLog causes coredump V2 [#2860]

2018-05-24 Thread Hans Nordeback
Hi Minh, yes gl_trace/gl_log can be put on the heap, you mean without any owner? But in this case when destructors for one of the threads has been run other threads should notice that some states may not be valid anymore,  e.g. that mutex_->good() returns false, but if mutex_ has been

Re: [devel] [PATCH 1/1] base: Destructor of TraceLog causes coredump V2 [#2860]

2018-05-23 Thread Hans Nordebäck
Hi Minh, yes you are right about the possibility for a segv, but using a std::shared_ptr instead of the naked ptr may be an option ? /Thanks Hans Från: Minh Hon Chau Skickat: den 24 maj 2018 02:34:13 Till: Hans Nordebäck; Anders

Re: [devel] [PATCH 1/1] base: Destructor of TraceLog causes coredump V2 [#2860]

2018-05-23 Thread Minh Hon Chau
Hi Hans, It is good to give an option to Mutex class not to abort. We can avoid the abort in mutex_unlock (as reported in coredump), but I feel the issue is still there. We may hit a problem (segv?) with "mutex_->good()" since the other thread is wiping out the mutex_ in destructor, it is a