Strange crash under Debian: sftkdb_fixupTemplateOut => __memset_sse2_unaligned_erms

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Strange crash under Debian: sftkdb_fixupTemplateOut => __memset_sse2_unaligned_erms

ISHIKAWA,chiaki
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange crash under Debian: sftkdb_fixupTemplateOut => __memset_sse2_unaligned_erms

ISHIKAWA,chiaki
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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-builds
>
>

_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange crash under Debian: sftkdb_fixupTemplateOut => __memset_sse2_unaligned_erms

ISHIKAWA,chiaki
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
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-builds
>>
>>
>
> _______________________________________________
> dev-builds mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-builds
>
>

_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange crash under Debian: sftkdb_fixupTemplateOut => __memset_sse2_unaligned_erms

ISHIKAWA,chiaki
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
 >>> [hidden email]
 >>> https://lists.mozilla.org/listinfo/dev-builds
 >>>
 >>>
 >>
 >> _______________________________________________
 >> dev-builds mailing list
 >> [hidden email]
 >> 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
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-builds
>>>
>>>
>>
>> _______________________________________________
>> dev-builds mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-builds
>>
>>
>
> _______________________________________________
> dev-builds mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-builds
>
>

_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange crash under Debian: sftkdb_fixupTemplateOut => __memset_sse2_unaligned_erms

Gregory Szorc-3
Thank you for tracking this down and submitting patches to fix -Werror=sign-compare problems.

For the record, this thread is a clear example of where the lack of a compiler warning/error led to a crash. In some contexts, I imagine this compiler warning could lead to a security vulnerability. And since the code in question is NSS, this very well could be one of those contexts :/

I implore the C++ module to audit the state of compiler warnings across the tree in the name of stability and security and to contemplate a formal policy around disabling compiler warnings. One of the ideas I floated during the Hawaii work week was to leverage the inline preprocessor syntax for disabling warnings at an occurrence level and not e.g. at a file, directory, or global level.

On Fri, Jan 27, 2017 at 6:58 AM, ISHIKAWA,chiaki <[hidden email]> wrote:
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
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-builds
>>>
>>>
>>
>> _______________________________________________
>> dev-builds mailing list
>> [hidden email]
>> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds



_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds



_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds



_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds


_______________________________________________
dev-builds mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-builds
Loading...