[
https://issues.apache.org/jira/browse/TS-4629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15359311#comment-15359311
]
ASF GitHub Bot commented on TS-4629:
------------------------------------
Github user dragon512 commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/780#discussion_r69330409
--- Diff: proxy/http/HttpSessionManager.cc ---
@@ -55,9 +55,10 @@ ServerSessionPool::ServerSessionPool() :
Continuation(new_ProxyMutex()), m_ip_po
void
ServerSessionPool::purge()
{
- for (IPHashTable::iterator last = m_ip_pool.end(), spot =
m_ip_pool.begin(); spot != last; ++spot) {
- spot->do_io_close();
- }
+ // @c do_io_close can free the instance which clears the intrusive links
and breaks the iterator.
+ // Therefore @c do_io_close is called on a post-incremented iterator.
+ for (IPHashTable::iterator last = m_ip_pool.end(), spot =
m_ip_pool.begin(); spot != last ; spot++->do_io_close())
+ ; // empty
m_ip_pool.clear();
--- End diff --
just a thought. As at this point the collection should be empty? do want to
add an assert that it is vs calling clear() as calling clear() on an empty
collection be a no-opt or a sign of a bug?
> ServerSessionPool::purge can use an invalid iterator
> ----------------------------------------------------
>
> Key: TS-4629
> URL: https://issues.apache.org/jira/browse/TS-4629
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Alan M. Carroll
>
> {{purge}} calls {{do_io_close}} on the session via an iterator and
> {{do_io_close}} can cause the session to be de-allocated. Because the
> container links are intrusive this causes the iterator to be come invalid
> even though it hasn't been removed from the container.
> Also, in fixing this, I noticed {{IPHashTable::iterator}} didn't have a
> postfix increment operator, which I added because it's perfect for this
> application.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
