search

sibojia / google-glog

Automatically exported from code.google.com/p/google-glog
Other
0 stars 0 forks source link

Recursive Mutex acquisiton in SetVLOGLevel causes SIGABRT #53

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. call SetVLOGLevel ... at all.

e.g.
$ cat <<EOF > example.cpp
> #include <glog/logging.h>
> 
> int main(int argc, char* argv[])
> {
>    google::InitGoogleLogging(argv[0])
>    google::InstallFailureSignalHandler();
>    google::SetVLOGLevel("e*", 2);
> 
>    return 0;
> }
> EOF
$ g++ -lglog -lpthread example.cpp 
$ ./a.out
*** Aborted at 1277834160 (unix time) try "date -d @1277834160" if you are 
using GNU date ***
PC: @   0xf14402 (unknown)
*** SIGABRT (@0x36fd) received by PID 14077 (TID 0xb7fb26d0) from PID 14077; 
stack trace: ***
    @   0xf14440 (unknown)
    @   0xbc9701 (unknown)
    @   0x1c8d27 google::InitVLOG3__()
    @   0x1c9035 google::SetVLOGLevel()

What is the expected output? What do you see instead?
The expected behavior depends on the context obviously, but it should, in 
general, change the vmodule settings (if VLOG_IS_ON hasn't been called already 
in that file). It certainly shouldn't do abort.

What version of the product are you using? On what operating system?
0.3.1 on Linux

Please provide any additional information below.

If you have a nicely working debug build of everything you get the more 
explicit:
*** Aborted at 1277834604 (unix time) try "date -d @1277834604" if you are 
using GNU date ***
PC: @   0x2b7402 (unknown)
*** SIGABRT (@0x491b) received by PID 18715 (TID 0xb7ee86d0) from PID 18715; 
stack trace: ***
    @   0x2b7440 (unknown)
    @   0xbc9701 (unknown)
    @  0x805461e glog_internal_namespace_::Mutex::Lock()
    @  0x805463b glog_internal_namespace_::MutexLock::MutexLock()
    @  0x80562f8 google::InitVLOG3__()
    @  0x8056671 google::SetVLOGLevel()

If you look at the source for InitVLOG3__ you will notice this lovely 
contradiction:
// NOTE: Individual VLOG statements cache the integer log level pointers.
// NOTE: This function must not allocate memory or require any locks.
bool InitVLOG3__(int32** site_flag, int32* site_default,
                 const char* fname, int32 verbose_level) {
  MutexLock l(&vmodule_lock);
/*...*/

which gets tickled when SetVLOGLevel() calls RAW_VLOG(1). Remove the offending 
lock (per the attached patch) and all is resolved... but I can't guarantee that 
this won't cause other thread safety problems elsewhre.

Original issue reported on code.google.com by donald.b.guy on 29 Jun 2010 at 6:14

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by shinichi...@gmail.com on 1 Jul 2010 at 7:11

GoogleCodeExporter commented 9 years ago 
alternatively you could just modify the scope of the lock in the SetVLOGLevel() 
such that the call to RAW_VLOG is not within that locked scope..

patch attached.

Original comment by JeffreyD...@gmail.com on 15 Sep 2010 at 1:42

Attachments:

GoogleCodeExporter commented 9 years ago 
Had this issue been fixed in the new release?

Original comment by m.ep...@gmail.com on 29 Apr 2011 at 2:09