You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: