Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signalhandler should avoid calling new/malloc. #78

Closed
yasushi-saito opened this issue Dec 11, 2015 · 0 comments
Closed

signalhandler should avoid calling new/malloc. #78

yasushi-saito opened this issue Dec 11, 2015 · 0 comments

Comments

@yasushi-saito
Copy link

I've seen the following problem with 0.3.4. The problem is that FlushLogFilesUnsafe() calls new LogDestination(), which may hang because the signal may have happened inside malloc. The following patch will fix this particular issue, but I notice that the system uses FILE* to write to log files, and FILE* isn't signal safe as far as I can tell.

I haven't reproduced the problem with the head version, but logging.cc hasn't changed since 0.3.4, so I suspect the problem is stil there.

diff --git a/src/logging.cc b/src/logging.cc
index b7c2f4c..982a308 100644
--- a/src/logging.cc
+++ b/src/logging.cc
@@ -572,7 +572,7 @@ inline void LogDestination::FlushLogFilesUnsafe(int min_seve
   // assume we have the log_mutex or we simply don't care
   // about it
   for (int i = min_severity; i < NUM_SEVERITIES; i++) {
-    LogDestination* log = log_destination(i);
+    LogDestination* log = log_destinations_[i];
     if (log != NULL) {
       // Flush the base fileobject_ logger directly instead of going
       // through any wrappers to reduce chance of deadlock.


#0  0x000000000086a783 in sys_futex (t=0x7fffbb6cc9a0, v=2, o=128, 
    a=0x117f538 <heap_checker_lock>) at ./src/base/linux_syscall_support.h:2097
#1  base::internal::SpinLockDelay (w=w@entry=0x117f538 <heap_checker_lock>, 
    value=2, loop=loop@entry=51302) at ./src/base/spinlock_linux-inl.h:88
#2  0x000000000086a66d in SpinLock::SlowLock (
    this=this@entry=0x117f538 <heap_checker_lock>) at src/base/spinlock.cc:133
#3  0x000000000086ccd2 in Lock (this=0x117f538 <heap_checker_lock>)
    at src/base/spinlock.h:71
#4  SpinLockHolder (l=0x117f538 <heap_checker_lock>, this=<synthetic pointer>)
    at src/base/spinlock.h:136
#5  NewHook (ptr=0x3330c60, size=144) at src/heap-checker.cc:578
#6  0x0000000000866709 in MallocHook::InvokeNewHookSlow (p=p@entry=0x3330c60, 
    s=s@entry=144) at src/malloc_hook.cc:514
#7  0x000000000088648b in InvokeNewHook (s=144, p=0x3330c60)
    at src/malloc_hook-inl.h:154
#8  tc_new (size=size@entry=144) at src/tcmalloc.cc:1622
#9  0x0000000000818152 in log_destination (severity=2) at src/logging.cc:771
#10 FlushLogFilesUnsafe (min_severity=min_severity@entry=0)
    at src/logging.cc:534
#11 google::FlushLogFilesUnsafe (min_severity=min_severity@entry=0)
    at src/logging.cc:1578
#12 0x0000000000821a00 in google::(anonymous namespace)::FailureSignalHandler (
    signal_number=4, signal_info=0x7fffbb6ccff0, ucontext=<optimized out>)
    at src/signalhandler.cc:325
#13 <signal handler called>
#14 _dl_x86_64_restore_sse () at ../sysdeps/x86_64/dl-trampoline.S:242
@ukai ukai closed this as completed in 0312301 Dec 17, 2015
ezegomez pushed a commit to ezegomez/glog that referenced this issue Sep 8, 2016
FlushLogFilesUnsafe would be called in FailureSignalHandler,
so should avoid calling new/malloc, which are not signal safe.

fixes google#78
durswd pushed a commit to durswd/glog that referenced this issue Sep 2, 2019
FlushLogFilesUnsafe would be called in FailureSignalHandler,
so should avoid calling new/malloc, which are not signal safe.

fixes google#78
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant