[
https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194508#comment-13194508
]
Brian Geffon commented on TS-1035:
----------------------------------
Lates Patch: TS1035.patch attached. I incorporated Igor's and Leif's
suggestions.
Because I don't have records.config access during global initialization I was
forced to make MAX_EVENT_THREADS and others configurable via ./configure, so we
have two new options /w ./configure which are:
--with-max-event-threads
max number of event threads [default=4096]
--with-max-threads-per-type
max number of threads per event type [default=3072]
Next, I used getconf ARG_MAX to so that LocalManager could build large command
line arguments in situations where a large number of ports are being used.
> EventProcessor::spawn_thread doesn't check that there is enough event threads
> and segfaults
> -------------------------------------------------------------------------------------------
>
> Key: TS-1035
> URL: https://issues.apache.org/jira/browse/TS-1035
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Affects Versions: 3.0.1
> Reporter: Brian Geffon
> Assignee: Brian Geffon
> Fix For: 3.1.3
>
> Attachments: TS1035.patch
>
>
> The easiest way to see this bug is to use several hundred ports with accept
> threads turned on. The bug exists because in I_EventProcessor.h there is a
> hard coded limit of 512 event threads and there is no check in spawn_thread
> that you haven't exceeded that limit so it will result in a segfault if
> you're creating too many threads. From what I can tell the best solution is
> an assertion that you haven't exceeded MAX_EVENT_THREADS.
> Patch is included.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
