Ping!

I'd like to try to get to the bottom of this cause; is there anything I can do 
to help figure this one out? Disabling the gzip plugin has eliminated the 
occurrences of this happening.

/dale

> On Feb 9, 2017, at 1:32 PM, Dale Ghent <[email protected]> wrote:
> 
> 
> Hey all;
> 
> For the past several days, I've been tracking down a crash that's happening 
> in traffic_server 6.2.1 that is happening fairly regularly on our cache 
> nodes. The basic pathology is: server_vc is NULL under some circumstances, 
> which has caused segfaults in code paths which do not guard for this 
> condition. This issue was raised last year in ticket TS-5046 and reported to 
> be fixed with the release of 6.2.1:
> 
> https://issues.apache.org/jira/browse/TS-5046
> 
> The fix was in PR 1222, by backporting the fixed for a different, related 
> issue reported in TS-4938, also reported as fixed in 6.2.1:
> 
> https://issues.apache.org/jira/browse/TS-4938
> 
> In the stack trace given in TS-5046, the person reported the segfault 
> happening in HttpSM::tunnel_handler_server(). While their path to get there 
> was different than ours, the effect was the same. In my case, the segfaults 
> always happen during processing in the gzip plugin:
> 
> https://paste.ec/paste/ZJnXEDC6#Rd-AeEkmmbsqM6E4rA/WuFdcgnUrv9By+rKO6eaxWmY
> 
> As a work-around, I put Masa's bandaid fix in HttpSM::tunnel_handler_server() 
> he mentioned in TS-5046. This of course avoids the null ptr deref there, but 
> now it occurs at the next point down the stack:
> 
> https://paste.ec/paste/+JwWMtuB#ew-87NnW1hQeFzwOCZ5GC+93EPF45YeJut/MtZwsdro
> 
> Obviously we can continue playing whackamole and put guards in for a NULL 
> server_vc in HttpServerSession::release(), however I feel that this probably 
> isn't the desired route. Questions such as "Is server_vc *ever* supposed to 
> be NULL?" and "Why would it be null in the first place?" persist, so I'm 
> turning to more seasoned eyes here for your thoughts. At any rate, 
> TS-5046/4938 do not appear to have completely addressed the situation.
> 
> /dale
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to