It looks one of my local patches may be causing this.
I am investigating now. (Strange, though, it used to work until about a
month ago...)
TIA
On 2016/12/23 14:47, ISHIKAWA,chiaki wrote:
I removed
ac_add_options --enable-valgrind
from my mozconfig and rebuilt TB
I now see the following (which I occasionally saw with
--enable-valgrind, but not reliably).
This is a DEBUG build.
Does this mean there is an improperly ordered locking/unlocking or
something like that?
...
[New Thread 0x7fff41b6a700 (LWP 4918)]
[New Thread 0x7fff41319700 (LWP 4919)]
[4731] ###!!! ASSERTION: missing ordering entry: 'proposed', file
/NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/DeadlockDetector.h,
line 235
[4731] ###!!! ASSERTION: missing ordering entry: 'current', file
/NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/DeadlockDetector.h,
line 238
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc33c7700 (LWP 4790)]
nsTArray_Impl<mozilla::BlockingResourceBase const*,
nsTArrayInfallibleAllocator>::AppendElement<mozilla::BlockingResourceBase
const*&>
(
this=<optimized out>, aItem=<optimized out>)
at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsTArray.h:2211
2211 elem_traits::Construct(elem, mozilla::Forward<Item>(aItem));
(gdb) where
#0 0x00007fffe74282ce in nsTArray_Impl<mozilla::BlockingResourceBase
const*,
nsTArrayInfallibleAllocator>::AppendElement<mozilla::BlockingResourceBase
const*&>((anonymous
namespace)::BlockingResourceBase const*&) (this=<optimized out>,
aItem=<optimized out>)
at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsTArray.h:2211
#1 0x00007fffe742e014 in (anonymous
namespace)::BlockingResourceBase::CheckAcquire() (aProposed=<optimized
out>, aLast=<optimized out>, this=<optimized out>) at
/NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/DeadlockDetector.h:249
#2 0x00007fffe742e014 in (anonymous
namespace)::BlockingResourceBase::CheckAcquire() (this=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/BlockingResourceBase.cpp:280
#3 0x00007fffe742e2c3 in (anonymous
namespace)::OffTheBooksMutex::Lock() (this=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/BlockingResourceBase.cpp:381
#4 0x00007fffe73e9bae in (anonymous
namespace)::TimerEventAllocator::Alloc(size_t) (this=<optimized out>)
at /NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/Monitor.h:35
#5 0x00007fffe73e9bae in (anonymous
namespace)::TimerEventAllocator::Alloc(size_t) (aMonitor=...,
this=<optimized out>)
#5 0x00007fffe73e9bae in (anonymous
namespace)::TimerEventAllocator::Alloc(size_t) (aMonitor=...,
this=<optimized out>)
at /NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/Monitor.h:78
#6 0x00007fffe73e9bae in (anonymous
namespace)::TimerEventAllocator::Alloc(size_t) (this=<optimized out>,
aSize=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerThread.cpp:221
#7 0x00007fffe73f7322 in
TimerThread::PostTimerEvent(already_AddRefed<nsTimerImpl>)
(aSize=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerThread.cpp:171
#8 0x00007fffe73f7322 in
TimerThread::PostTimerEvent(already_AddRefed<nsTimerImpl>)
(this=<optimized out>, aTimerRef=...)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerThread.cpp:699
#9 0x00007fffe73f7c9c in TimerThread::Run() (this=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerThread.cpp:488
#10 0x00007fffe73fad61 in nsThread::ProcessNextEvent(bool, bool*)
(this=<optimized out>, aMayWait=<optimized out>, aResult=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/nsThread.cpp:1213
#11 0x00007fffe743a814 in NS_ProcessNextEvent(nsIThread*, bool)
(aThread=<optimized out>, aMayWait=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsThreadUtils.cpp:381
#12 0x00007fffe794bfb3 in (anonymous
namespace)::ipc::MessagePumpForNonMainThreads::Run((anonymous
namespace)::MessagePump::Delegate*) (this=<optimized out>,
aDelegate=<optimized out>)
at /NREF-COMM-CENTRAL/comm-central/mozilla/ipc/glue/MessagePump.cpp:368
#13 0x00007fffe790bed6 in MessageLoop::RunInternal() (this=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:232
#14 0x00007fffe790bf1f in MessageLoop::RunHandler() (this=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:225
#15 0x00007fffe790c2f9 in MessageLoop::Run() (this=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:205
#16 0x00007fffe73ff14d in nsThread::ThreadFunc(void*) (aArg=<optimized
out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/nsThread.cpp:467
#17 0x00007ffff7f746ba in _pt_root (arg=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/nsprpub/pr/src/pthreads/ptthread.c:216
#18 0x00007ffff7bc4464 in start_thread (arg=0x7fffc33c7700)
at pthread_create.c:333
#19 0x00007ffff6e679df in clone ()
at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
On 2016/12/22 9:43, ISHIKAWA,chiaki wrote:
Hi,
I am building C-C TB under Debian GNU/linux 64-bit.
It has worked well.
Strangely, though, starting toward the end of last month, and this week
I noticed a strange crash during with the GDB backtrace pointing to a
memory allignment error during a call memset()?
This happens when TB starts up and tries to show the list of messages
and then the segmentation error or something.
#0 0x00007ffff6e031f3 in __memset_sse2_unaligned_erms ()
at
../sysdeps/x86_64/multiarch/../multiarch/memset-vec-unaligned-erms.S:175
#1 0x00007fffdc04c43a in sftkdb_fixupTemplateOut (template=<optimized
out>, objectID=<optimized out>, ntemplate=<optimized out>,
count=<optimized out>, handle=<optimized out>)
at
/NREF-COMM-CENTRAL/comm-central/mozilla/security/nss/lib/softoken/sftkdb.c:367
#2 0x00007fffdc04d078 in sftkdb_GetAttributeValue (handle=<optimized
out>, objectID=<optimized out>, template=<optimized out>,
count=<optimized out>)
at /NREF-COMM-CENTRAL/comm-central/mozilla/security/nss/lib/soft
In the last few days, I recall seeing someone mention a random startup
crash observed under Debian (I think it was related to FF, though).
Does anyone using Debian experience similar crash today?
Actually, the crash disappeared around Dec 7th after a daily source
update and Debian's package update.
I did not check it until the day before. Then after updating the source
files and packages, I realize
the problem is back...
TIA
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
