Bugzilla

(In reply to Wayne Mery (:wsmwk) from comment #30)
> Any new details or related bug reports?

Thank you for the reminder, Wayne.

I think I have a better understanding of the object life time and how to handle pointers to them at shutdown time, which is exactly the issue here,  thanks to the work I have put to the bugzilla 1956408 recently.
That bugzilla is to modify the IMAP module to experience less data race/deadlock/unnecessary sleep-wake up cycle (typically 60 seconds sleep and wakeup cycle).

So I will come back to this once I fixed that bug.

But I found a  genuine GC bug to boot during testing IMAP module under TSAN. :-( 
Initially, I thought it is an issue caused by DEBUG-only assertions, but I could not erase the issue after tinkering with the source code.
I analyzed the TSAN stack trace of a new data race I caught very recently. And I suspected a bug in GC handling of so-called WeakMap,  and instrumented what (which thread) is doing what GC action carefully, and found an issue about data races.
Basically, the lock was held to protect a node. So far, so good.
The node is part of a linked list, and GC was trying to remove the node from the list.
The node itself was under a lock. However, in a linked list, the predecessor node's ->_next and the successor node's ->_prev fields need to be rewritten and thus needs to be protected in the same lock. They were not.
Thus data race.
TSAN testing revealed this. The slow down x5~x20 makes the window large enough for me to hit the race.

I am going to file the bugzilla for that now.
Untill this GC bug is fixed in the GC code, I have to whitelist the GC race which may not be quite correct approach, but I have to live with it to make sure the new IMAP code does not crash under stress testing, which I am doing right now. GC's TSAN race interfered with the test and I needed to investigate and found the issue.

All in all, my knowledge of how to cope with refcounted pointers created on main thread (that does I/O) 
that had been passed to objects created by non-main thread has progressed siginificantly.

So, I hope I can fix this in a satisfactory manner once I fix the IMAP module in a satisfactory manner.

(In reply to Wayne Mery (:wsmwk) from comment #30)
> Any new details or related bug reports?

Thank you for the reminder, Wayne.

I think I have a better understanding of the object life time and how to handle pointers to them at shutdown time, which is exactly the issue here,  thanks to the work I have put to the bug 1956408 recently.
That bugzilla is to modify the IMAP module to experience less data race/deadlock/unnecessary sleep-wake up cycle (typically 60 seconds sleep and wakeup cycle).

So I will come back to this once I fixed that bug.

But I found a  genuine GC bug to boot during testing IMAP module under TSAN. :-( 
Initially, I thought it is an issue caused by DEBUG-only assertions, but I could not erase the issue after tinkering with the source code.
I analyzed the TSAN stack trace of a new data race I caught very recently. And I suspected a bug in GC handling of so-called WeakMap,  and instrumented what (which thread) is doing what GC action carefully, and found an issue about data races.
Basically, the lock was held to protect a node. So far, so good.
The node is part of a linked list, and GC was trying to remove the node from the list.
The node itself was under a lock. However, in a linked list, the predecessor node's ->_next and the successor node's ->_prev fields need to be rewritten and thus needs to be protected in the same lock. They were not.
Thus data race.
TSAN testing revealed this. The slow down x5~x20 makes the window large enough for me to hit the race.

I am going to file the bugzilla for that now.
Untill this GC bug is fixed in the GC code, I have to whitelist the GC race which may not be quite correct approach, but I have to live with it to make sure the new IMAP code does not crash under stress testing, which I am doing right now. GC's TSAN race interfered with the test and I needed to investigate and found the issue.

All in all, my knowledge of how to cope with refcounted pointers created on main thread (that does I/O) 
that had been passed to objects created by non-main thread has progressed siginificantly.

So, I hope I can fix this in a satisfactory manner once I fix the IMAP module in a satisfactory manner.