Sorry for top-posting, but
It turns out a few added patch lines to address the changes in the code
in December were causing the issue.
I figured out the issue.
In the code, unsigned long value was assigned (-1) to indicate an
invalid value. [I think it is not a great coding practice, but I digress.]
When it was later compared to (-1)
if ( value == -1 )
the compiler generated signed and unsigned comparison warning, which is
now treated as error in my local strict setting.
In my haste, initially I did the casting as follows
value == (unsigned) -1
which was incorrect.
It ought to be
(signed) value == -1.
Or better still
(long) value == -1
Why it was wrong.
|value == (unsigned) -1| seems to have generated the code which is
equivalent to
value == 0x00000000FFFFFFFF (only the lower 4 bytes are set to 0xFF) on this
machine x86_64 (Debian GNU/Linux)
and of course, when the unsigned long value has (-1) [0xFFFFFFFFFFFFFFF 8
bytes],
0xFFFFFFFFFFFFFFFF (8bytes) == 0x00000000FFFFFFFF
does not hold and thus the comparison failed (?) and this was an
unexpected behavior, thus the program looked at invalid data area, etc.
since the if-expr evaluated to an expected value.
I updated the patches in
Bug 1307958 - -Werror=sign-compare smorgasbord
to fix this latest issues.
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
>>
>>
>
On 2016/12/23 16:06, ISHIKAWA,chiaki wrote:
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
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
