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 <ishik...@yk.rim.or.jp> 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::Blockin > gResourceBase > >> 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::Blockin > gResourceBase > >> 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/DeadlockD > etector.h:249 > >> #2 0x00007fffe742e014 in (anonymous > >> namespace)::BlockingResourceBase::CheckAcquire() (this=<optimized out>) > >> at > >> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/BlockingR > esourceBase.cpp:280 > >> > >> > >> #3 0x00007fffe742e2c3 in (anonymous > >> namespace)::OffTheBooksMutex::Lock() (this=<optimized out>) > >> at > >> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/BlockingR > esourceBase.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/TimerT > hread.cpp:221 > >> #7 0x00007fffe73f7322 in > >> TimerThread::PostTimerEvent(already_AddRefed<nsTimerImpl>) > >> (aSize=<optimized out>) > >> at > >> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerT > hread.cpp:171 > >> #8 0x00007fffe73f7322 in > >> TimerThread::PostTimerEvent(already_AddRefed<nsTimerImpl>) > >> (this=<optimized out>, aTimerRef=...) > >> at > >> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerT > hread.cpp:699 > >> #9 0x00007fffe73f7c9c in TimerThread::Run() (this=<optimized out>) > >> at > >> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerT > hread.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/nsThreadU > tils.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-unaligne > d-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::Blockin >>> gResourceBase >>> 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::Blockin >>> gResourceBase >>> 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/DeadlockD >>> etector.h:249 >>> #2 0x00007fffe742e014 in (anonymous >>> namespace)::BlockingResourceBase::CheckAcquire() (this=<optimized out>) >>> at >>> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/BlockingR >>> esourceBase.cpp:280 >>> >>> >>> #3 0x00007fffe742e2c3 in (anonymous >>> namespace)::OffTheBooksMutex::Lock() (this=<optimized out>) >>> at >>> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/BlockingR >>> esourceBase.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/TimerT >>> hread.cpp:221 >>> #7 0x00007fffe73f7322 in >>> TimerThread::PostTimerEvent(already_AddRefed<nsTimerImpl>) >>> (aSize=<optimized out>) >>> at >>> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerT >>> hread.cpp:171 >>> #8 0x00007fffe73f7322 in >>> TimerThread::PostTimerEvent(already_AddRefed<nsTimerImpl>) >>> (this=<optimized out>, aTimerRef=...) >>> at >>> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerT >>> hread.cpp:699 >>> #9 0x00007fffe73f7c9c in TimerThread::Run() (this=<optimized out>) >>> at >>> /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerT >>> hread.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-unaligne >>>> d-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 >
_______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
