(In reply to ISHIKAWA, Chiaki from comment #13) > (In reply to Daniel Veditz [:dveditz] from comment #12) > > Please clear the sec-low to trigger a re-triage if you find that the freed/poisoned object is anything that is not an nsIFrame. > > I think the problem was caused by the access to > |mUpdateBatchNest|, i.e. this ->mUpdateBatchNest. > > It is a bit hard to figure out exactly where the pointer points at a block since the > ASAN compilation seems to align variables a bit differently from ordinary compilation > to make it easy to detect invalid access to > variables by separating them apart, etc. unless they are the members of an array. > valgrind would have made it easy to verify this, but > unfortunately, mochitest of TB does not run under valgrind currently. Silly me, I can simply print out the address of |mUpdateBatchNest| and let the original bug to occur and recorded by ASAN binary, then compare the addresses. Bingo. The problematic address is indeed &mUpdateBatchNest. ``` 1:57.14 GECKO(727918) {streamdebug} closing: outputStream (= 0x606001459288 )->Close() 'before possible Close()' in ChangeFlags at line 990 of /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp 1:57.14 GECKO(727918) {streamdebug} value: outputStream = 0x606001459288 'setting to nullptr' in ChangeFlags at line 996 of /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp 1:57.14 GECKO(727918) &mUpdateBatchNest = 0x6250005745b4 1:57.14 GECKO(727918) &mUpdateBatchNest = 0x6250018c559c 1:57.14 GECKO(727918) ================================================================= 1:57.14 GECKO(727918) ==727918==ERROR: AddressSanitizer: use-after-poison on address 0x6250018c559c at pc 0x7f3a7d08c90a bp 0x7fffdacf1c10 sp 0x7fffdacf1c08 1:57.14 GECKO(727918) READ of size 4 at 0x6250018c559c thread T0 1:57.20 GECKO(727918) error: address range table at offset 0xd50 has an invalid tuple (length = 0) at offset 0xd60 1:57.20 GECKO(727918) #0 0x7f3a7d08c909 in nsTreeBodyFrame::RowCountChanged(int, int) /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:1614:7 1:57.20 GECKO(727918) #1 0x7f3a6e92c12b in nsMsgDBView::NoteChange(unsigned int, int, int) /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/base/src/nsMsgDBView.cpp:5951:16 ``` I am taking off
Bug 1677194 Comment 17 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to ISHIKAWA, Chiaki from comment #13) > (In reply to Daniel Veditz [:dveditz] from comment #12) > > Please clear the sec-low to trigger a re-triage if you find that the freed/poisoned object is anything that is not an nsIFrame. > > I think the problem was caused by the access to > |mUpdateBatchNest|, i.e. this ->mUpdateBatchNest. > > It is a bit hard to figure out exactly where the pointer points at a block since the > ASAN compilation seems to align variables a bit differently from ordinary compilation > to make it easy to detect invalid access to > variables by separating them apart, etc. unless they are the members of an array. > valgrind would have made it easy to verify this, but > unfortunately, mochitest of TB does not run under valgrind currently. Silly me, I can simply print out the address of |mUpdateBatchNest| and let the original bug to occur and recorded by ASAN binary, then compare the addresses. Bingo. The problematic address is indeed &mUpdateBatchNest. ``` 1:57.14 GECKO(727918) {streamdebug} closing: outputStream (= 0x606001459288 )->Close() 'before possible Close()' in ChangeFlags at line 990 of /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp 1:57.14 GECKO(727918) {streamdebug} value: outputStream = 0x606001459288 'setting to nullptr' in ChangeFlags at line 996 of /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/local/src/nsMsgBrkMBoxStore.cpp 1:57.14 GECKO(727918) &mUpdateBatchNest = 0x6250005745b4 1:57.14 GECKO(727918) &mUpdateBatchNest = 0x6250018c559c 1:57.14 GECKO(727918) ================================================================= 1:57.14 GECKO(727918) ==727918==ERROR: AddressSanitizer: use-after-poison on address 0x6250018c559c at pc 0x7f3a7d08c90a bp 0x7fffdacf1c10 sp 0x7fffdacf1c08 1:57.14 GECKO(727918) READ of size 4 at 0x6250018c559c thread T0 1:57.20 GECKO(727918) error: address range table at offset 0xd50 has an invalid tuple (length = 0) at offset 0xd60 1:57.20 GECKO(727918) #0 0x7f3a7d08c909 in nsTreeBodyFrame::RowCountChanged(int, int) /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/xul/tree/nsTreeBodyFrame.cpp:1614:7 1:57.20 GECKO(727918) #1 0x7f3a6e92c12b in nsMsgDBView::NoteChange(unsigned int, int, int) /NEW-SSD/NREF-COMM-CENTRAL/mozilla/comm/mailnews/base/src/nsMsgDBView.cpp:5951:16 ``` I am clearing sec-low keyword.