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 taking off
(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.

Back to Bug 1677194 Comment 17