[
https://issues.apache.org/jira/browse/TS-4503?focusedWorklogId=28663&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-28663
]
ASF GitHub Bot logged work on TS-4503:
--------------------------------------
Author: ASF GitHub Bot
Created on: 09/Sep/16 20:19
Start Date: 09/Sep/16 20:19
Worklog Time Spent: 10m
Work Description: Github user persiaAziz commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/991#discussion_r78242362
--- Diff: proxy/Main.cc ---
@@ -908,7 +908,7 @@ check_fd_limit()
if (fds_throttle > fds_limit + THROTTLE_FD_HEADROOM) {
int new_fds_throttle = fds_limit - THROTTLE_FD_HEADROOM;
if (new_fds_throttle < 1) {
- MachineFatal("too few file descritors (%d) available", fds_limit);
+ ink_abort("too few file descritors (%d) available", fds_limit);
--- End diff --
Oh I should use ink_abort here since Fatal does not call abort(). I think
the original idea was to terminate immediately at this point without memory
cleanup
Issue Time Tracking
-------------------
Worklog Id: (was: 28663)
Time Spent: 3h 10m (was: 3h)
> MachineFatal should shutdown without cleanup
> --------------------------------------------
>
> Key: TS-4503
> URL: https://issues.apache.org/jira/browse/TS-4503
> Project: Traffic Server
> Issue Type: Bug
> Reporter: Susan Hinrichs
> Assignee: Syeda Persia Aziz
> Fix For: 7.0.0
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> When MachineFatalClass::raise() is called, it prints a message to the log and
> then calls exit. exit causes memory cleanup to be called. But if we are in
> such bad state that MachineFatal is called, it is quite likely that memory is
> messed up.
> We saw a crash where MachineFatal is called in thread 84. This stack has the
> real error. But the stack that got reported was on thread 1 in class
> destructor logic. It would have been better if ATS failed immediately and
> the stack on thread 84 was reported.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
