Github user gtenev commented on the issue:
https://github.com/apache/trafficserver/pull/1100
I was actually thinking to propose just adding a
âcatch-all-delete-streamâ call in `destroy()` before `THREAD_FREE()` in 7.0.
It seems to me that the point of this Jira TS-4813 / this PR got somehow
lost so I would like to reiterate.
Missing a stream deletion from `DLL<>` before calling `THREAD_FREE()` COULD
lead to breaking the `DLL<>` and then if that happens `DLL<>` traversals ALWAYS
ends up in infinite loop.
Host became dysfunctional pretty often because of this (time to live 1-3
days per host) and it took long time to debug/prove.
This is my (practical?) attempt to make sure we donât get stuck in this
debugging again regardless of past/current/future âdelete streamâ bugs (as
long us we use `THREAD_ALLOC_INIT/THREAD_FREE` + `DLL<>` of course).
I wanted to propose a "catch-all-delete-stream" safety net in both 6.2.1
and 7.0.0 because I think it would be hard to guarantee that the next commit
would not introduce this weakness again.
This is my first read of the H2 code so I can see how the proposed fix can
be sub-optimal and will gladly change it, I also hope I provided enough
reasoning for best results :).
I am pretty confident in my debugging data/conclusions but just by reading
the code or by sorting through Jiras that âmay helpâ I can only guess if
the new 7.0 version or back-ports to 6.2.1 definitely fix the issue until I
test/verify.
We could close this PR:
- If we are confident all âfixes in this areaâ from 7.0 can be
back-ported to 6.2.1 and that the issue will be fixed
- AND If adding the proposed safety net does not make any/enough sense
Cheers!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
