[jira] [Commented] (TS-3603) Debug Assert occurs in UnixNetVConnection::set_enabled when accept_threads are disabled

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-3603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14545694#comment-14545694 ] 

ASF subversion and git services commented on TS-3603:
-----------------------------------------------------

Commit ef467a2be79fc962ae0ec042ef9f6e871d3a775f in trafficserver's branch refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ef467a2 ]

TS-3603: Debug assert due to missing lock when accept_threads are disabled.


> Debug Assert occurs in UnixNetVConnection::set_enabled when accept_threads are disabled
> ---------------------------------------------------------------------------------------
>
>                 Key: TS-3603
>                 URL: https://issues.apache.org/jira/browse/TS-3603
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Network
>            Reporter: Susan Hinrichs
>            Assignee: Susan Hinrichs
>         Attachments: TS-3603.diff
>
>
> This was found while tracking down TS-3597.  The assert stack is in a comment on that bug.
> When you don't have a dedicated assert thread, the mutex is not locked before going into the do_io_read to process the accept event.  In the dedicated thread case, you end up exercising UnixNetVConnection::acceptEvent which does grab the mutex.
> May be a relatively harmless error.  Since this is a newly created VC, there should be no race conditions on it.  But violating locking assumptions seem like a really bad idea.  Especially since grabbing a lock on a supposedly uncontended object should be cheap.
> A 5.3.x patch is attached to this bug which solves the problem on my build.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)