[jira] [Updated] (TS-5090) Cache hit ratio deteriorating over time with CLFUS

2016-12-13 Thread Steve Malenfant (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-5090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Malenfant updated TS-5090:

Attachment: graph-ram-cache.png

> Cache hit ratio deteriorating over time with CLFUS
> --
>
> Key: TS-5090
> URL: https://issues.apache.org/jira/browse/TS-5090
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Leif Hedstrom
> Fix For: sometime
>
> Attachments: RAM Cache.png, graph-ram-cache.png
>
>
> We've observed poor cache hit ratio with the CLFUS, where it starts doing 
> great, but over ~1 day, the cache hit ratio deteriorates. It's to the point 
> where the LRU + seen-filter=1 is 2-3x better. In addition, the RAM cache hit 
> ratio on the LRU stays consistent over time.
> At first, I thought it was only our particular use case, but it seems others 
> have confirmed the same behavior.



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


[jira] [Commented] (TS-5090) Cache hit ratio deteriorating over time with CLFUS

2016-12-13 Thread Steve Malenfant (JIRA)

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

Steve Malenfant commented on TS-5090:
-

Confirming Leif's observation. In a VOD only test environment (HLS), we could 
see CLFUS TCP_MEM_HIT going down to zero after ~20 hours. I've then changed the 
ram_cache algorithm to LRU and use_seen_filter=1 and TCP_MEM_HIT were now 
consistent.

Attaching a graph here as well. Red is CLFUS and Blue is LRU. 

> Cache hit ratio deteriorating over time with CLFUS
> --
>
> Key: TS-5090
> URL: https://issues.apache.org/jira/browse/TS-5090
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Leif Hedstrom
> Attachments: RAM Cache.png
>
>
> We've observed poor cache hit ratio with the CLFUS, where it starts doing 
> great, but over ~1 day, the cache hit ratio deteriorates. It's to the point 
> where the LRU + seen-filter=1 is 2-3x better. In addition, the RAM cache hit 
> ratio on the LRU stays consistent over time.
> At first, I thought it was only our particular use case, but it seems others 
> have confirmed the same behavior.



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


[jira] [Commented] (TS-3304) segfault in libtsutils

2015-01-21 Thread Steve Malenfant (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14285620#comment-14285620
 ] 

Steve Malenfant commented on TS-3304:
-

From the records.config, not sure if this has anything to do with it since 
that's the only place I could see a reference to localhost in the config.
records.config:CONFIG proxy.config.log.hostname STRING localhost

With hostdb and dns debug :

[Jan 21 12:18:01.733] Server {0x2aaca5e1d700} DEBUG: (hostdb) hostname = 
localhost
[Jan 21 12:18:11.733] Server {0x2aac9dc7c000} DEBUG: (hostdb) probe 127.0.0.1 
c3aab60f33f8019c 1 [ignore_timeout = 0]
[Jan 21 12:18:11.734] Server {0x2aac9dc7c000} DEBUG: (hostdb) immediate answer 
for 127.0.0.1
[Jan 21 12:18:11.734] Server {0x2aac9dc7c000} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Jan 21 12:18:11.734] Server {0x2aac9dc7c000} DEBUG: (hostdb) immediate answer 
for 127.0.0.1
[Jan 21 12:18:11.734] Server {0x2aac9dc7c000} DEBUG: (hostdb) hostname = 
localhost
[Jan 21 12:18:21.734] Server {0x2aaca4a09700} DEBUG: (hostdb) probe 127.0.0.1 
c3aab60f33f8019c 1 [ignore_timeout = 0]
[Jan 21 12:18:21.734] Server {0x2aaca4a09700} DEBUG: (hostdb) immediate answer 
for 127.0.0.1
[Jan 21 12:18:21.734] Server {0x2aaca4a09700} DEBUG: (hostdb) probe  
aa30de0f80a82135 1 [ignore_timeout = 0]
[Jan 21 12:18:21.734] Server {0x2aaca4a09700} DEBUG: (hostdb) serving stale 
entry 86400 | 6 | 86400 as requested by config
[Jan 21 12:18:21.734] Server {0x2aaca4a09700} DEBUG: (hostdb) serving stale 
entry 86400 | 6 | 86400 as requested by config
[Jan 21 12:18:21.734] Server {0x2aaca4a09700} DEBUG: (hostdb) stale 86400 
1421756537 86400, using it and refreshing it
NOTE: Traffic Server received Sig 11: Segmentation fault
/opt/trafficserver/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0x381b60f710)[0x2aac9d2e5710]
/opt/trafficserver/lib/libtsutil.so.4(_Z13ink_inet_addrPKc+0x8)[0x2aac9d0ba1d8]
/opt/trafficserver/bin/traffic_server(_Z5probeP10ProxyMutexRK9HostDBMD5b+0x315)[0x5e0df5]
/opt/trafficserver/bin/traffic_server(_ZN15HostDBProcessor5getbyEP12ContinuationPKciPK8sockaddrb12HostResStylei+0x4e4)[0x5e2b34]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM24do_hostdb_reverse_lookupEv+0x4c)[0x517f2c]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x778)[0x52f028]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM16do_hostdb_lookupEv+0x282)[0x518242]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0xb9a)[0x52f44a]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x5284fa]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x52ea9a]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1da)[0x52ea8a]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x5284fa]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x52ea9a]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM17handle_api_returnEv+0x32a)[0x5284fa]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x1ea)[0x52ea9a]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM32state_read_client_request_headerEiPv+0x226)[0x52fef6]
/opt/trafficserver/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0xd8)[0x52a5b8]
/opt/trafficserver/bin/traffic_server[0x68793b]
/opt/trafficserver/bin/traffic_server[0x689ec4]
/opt/trafficserver/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x67fb12]
/opt/trafficserver/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6ac8cf]
/opt/trafficserver/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x6ad273]
/opt/trafficserver/bin/traffic_server[0x6abc2a]
/lib64/libpthread.so.0(+0x381b6079d1)[0x2aac9d2dd9d1]


 segfault in libtsutils
 --

 Key: TS-3304
 URL: https://issues.apache.org/jira/browse/TS-3304
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Steve Malenfant
Assignee: Leif Hedstrom
 Fix For: 5.3.0


 Getting multiple segfaults per day on 4.2.1. 
 [4324544.324222] [ET_NET 23][10504]: segfault at 0 ip 2acd66546168 sp 
 2acd71f190b8 error 4 in libtsutil.so.4.2.1[2acd66521000+34000]
 [4410696.820857] [ET_NET 19][22738]: segfault at 0 ip 2af09f339168 sp 
 2af0aa9230b8 error 4 in libtsutil.so.4.2.1[2af09f314000+34000]
 [4497039.474253] [ET_NET 12][34872]: segfault at 0 ip 2ad17e6a1168 sp 
 2ad1896100b8 error 4 in libtsutil.so.4.2.1[2ad17e67c000+34000]
 [4583372.073916] [ET_NET 3][46994]: segfault at 0 ip 2aced4227168 sp 
 2aceda7d80b8 error 4 in libtsutil.so.4.2.1[2aced4202000+34000]
 [4756046.944373] [ET_NET 22][10799]: segfault at 0 ip 2b1771f76168 sp 
 2b177d9130b8 error 4 in libtsutil.so.4.2.1[2b1771f51000+34000]
 Stack Trace :
 (gdb) bt
 #0  ink_inet_addr (s=value optimized 

[jira] [Commented] (TS-3304) segfault in libtsutils

2015-01-20 Thread Steve Malenfant (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283929#comment-14283929
 ] 

Steve Malenfant commented on TS-3304:
-

Nothing like that... Currently enabled dns.* | hostdb.* debug. Will see what 
causes this (if that would help).
In a pre-production environment, the problem occurs every day around the same 
time. Although happens randomly in the lab.
It also doesn't seem to be caused by usage (there is nothing reaching out to 
those ATS servers right now).

 segfault in libtsutils
 --

 Key: TS-3304
 URL: https://issues.apache.org/jira/browse/TS-3304
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Steve Malenfant
Assignee: Leif Hedstrom
 Fix For: 5.3.0


 Getting multiple segfaults per day on 4.2.1. 
 [4324544.324222] [ET_NET 23][10504]: segfault at 0 ip 2acd66546168 sp 
 2acd71f190b8 error 4 in libtsutil.so.4.2.1[2acd66521000+34000]
 [4410696.820857] [ET_NET 19][22738]: segfault at 0 ip 2af09f339168 sp 
 2af0aa9230b8 error 4 in libtsutil.so.4.2.1[2af09f314000+34000]
 [4497039.474253] [ET_NET 12][34872]: segfault at 0 ip 2ad17e6a1168 sp 
 2ad1896100b8 error 4 in libtsutil.so.4.2.1[2ad17e67c000+34000]
 [4583372.073916] [ET_NET 3][46994]: segfault at 0 ip 2aced4227168 sp 
 2aceda7d80b8 error 4 in libtsutil.so.4.2.1[2aced4202000+34000]
 [4756046.944373] [ET_NET 22][10799]: segfault at 0 ip 2b1771f76168 sp 
 2b177d9130b8 error 4 in libtsutil.so.4.2.1[2b1771f51000+34000]
 Stack Trace :
 (gdb) bt
 #0  ink_inet_addr (s=value optimized out) at ink_inet.cc:107
 #1  0x005e0df5 in is_dotted_form_hostname (mutex=0x1d32cb0, md5=..., 
 ignore_timeout=false) at P_HostDBProcessor.h:545
 #2  probe (mutex=0x1d32cb0, md5=..., ignore_timeout=false) at HostDB.cc:668
 #3  0x005e2b34 in HostDBProcessor::getby (this=value optimized out, 
 cont=0x2b514cc749d0, hostname=0x0, len=value optimized out, 
 ip=0x2b50e8f092b0, aforce_dns=false, host_res_style=HOST_RES_NONE, 
 dns_lookup_timeout=0)
 at HostDB.cc:772
 #4  0x00517f2c in getbyaddr_re (this=0x2b514cc749d0) at 
 ../../iocore/hostdb/I_HostDBProcessor.h:417
 #5  HttpSM::do_hostdb_reverse_lookup (this=0x2b514cc749d0) at HttpSM.cc:3968
 #6  0x0052f028 in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6932
 #7  0x00518242 in HttpSM::do_hostdb_lookup (this=0x2b514cc749d0) at 
 HttpSM.cc:3950
 #8  0x0052f44a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6925
 #9  0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
 HttpSM.cc:1559
 #10 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6825
 #11 0x0052ea8a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:7224
 #12 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
 HttpSM.cc:1559
 #13 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6825
 #14 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
 HttpSM.cc:1559
 #15 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6825
 #16 0x0052fef6 in HttpSM::state_read_client_request_header 
 (this=0x2b514cc749d0, event=100, data=value optimized out) at HttpSM.cc:821
 #17 0x0052a5b8 in HttpSM::main_handler (this=0x2b514cc749d0, 
 event=100, data=0x2b514802ca08) at HttpSM.cc:2539
 #18 0x0068793b in handleEvent (event=value optimized out, 
 vc=0x2b514802c900) at ../../iocore/eventsystem/I_Continuation.h:146
 #19 read_signal_and_update (event=value optimized out, vc=0x2b514802c900) 
 at UnixNetVConnection.cc:138
 #20 0x00689ec4 in read_from_net (nh=0x2b50e2e17c10, 
 vc=0x2b514802c900, thread=value optimized out) at UnixNetVConnection.cc:320
 #21 0x0067fb12 in NetHandler::mainNetEvent (this=0x2b50e2e17c10, 
 event=value optimized out, e=value optimized out) at UnixNet.cc:384
 #22 0x006ac8cf in handleEvent (this=0x2b50e2e14010, e=0x1a9ef30, 
 calling_code=5) at I_Continuation.h:146
 #23 EThread::process_event (this=0x2b50e2e14010, e=0x1a9ef30, calling_code=5) 
 at UnixEThread.cc:145
 #24 0x006ad273 in EThread::execute (this=0x2b50e2e14010) at 
 UnixEThread.cc:269
 #25 0x006abc2a in spawn_thread_internal (a=0x198f820) at Thread.cc:88
 #26 0x2b50e026b9d1 in start_thread () from /lib64/libpthread.so.0
 #27 0x00381b2e8b6d in clone () from /lib64/libc.so.6
  



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


[jira] [Commented] (TS-3304) segfault in libtsutils

2015-01-20 Thread Steve Malenfant (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14283964#comment-14283964
 ] 

Steve Malenfant commented on TS-3304:
-

This would make a lot of sense. The only origin server configured in 
pre-production (remap rule) has a TTL of 86400. The problem seems to occur 
daily where the time is about 2-4 minutes less everyday. See here for yourself 
(timestamp). I guess I can try to reproduce by using an origin server with TTL 
set lower.

/var/log/messages-20141228:Dec 21 12:00:25 psp6cdatsec02 kernel: 
[764153.984271] [ET_NET 8][20967]: segfault at 0 ip 2b7d79d921d8 sp 
2b7d8100a0b8 error 4 in libtsutil.so.4.2.1[2b7d79d6d000+34000]
/var/log/messages-20141228:Dec 22 11:54:32 psp6cdatsec02 kernel: 
[850232.881960] [ET_NET 1][5111]: segfault at 0 ip 2ab0e67ac1d8 sp 
2ab0ed30d0b8 error 4 in libtsutil.so.4.2.1[2ab0e6787000+34000]
/var/log/messages-20141228:Dec 23 11:48:29 psp6cdatsec02 kernel: 
[936301.329301] [ET_NET 28][21668]: segfault at 0 ip 2ac5c22361d8 sp 
2ac5ca9230b8 error 4 in libtsutil.so.4.2.1[2ac5c2211000+34000]
/var/log/messages-20141228:Dec 24 11:43:46 psp6cdatsec02 kernel: 
[1022449.436637] [ET_NET 10][38230]: segfault at 0 ip 2adbccb641d8 sp 
2adbcff4e0b8 error 4 in libtsutil.so.4.2.1[2adbccb3f000+34000]
/var/log/messages-20141228:Dec 26 11:31:30 psp6cdatsec02 kernel: 
[1194576.265730] [ET_NET 3][6230]: segfault at 0 ip 2b2f7b18b1d8 sp 
2b2f81f190b8 error 4 in libtsutil.so.4.2.1[2b2f7b166000+34000]
/var/log/messages-20141228:Dec 27 11:25:27 psp6cdatsec02 kernel: 
[1280645.089066] [ET_NET 25][38961]: segfault at 0 ip 2b9cd451a1d8 sp 
2b9cdc9030b8 error 4 in libtsutil.so.4.2.1[2b9cd44f5000+34000]
/var/log/messages-20150104:Dec 28 11:19:24 psp6cdatsec02 kernel: 
[1366713.531696] [ET_NET 28][6960]: segfault at 0 ip 2b79171871d8 sp 
2b791f8320b8 error 4 in libtsutil.so.4.2.1[2b7917162000+34000]
/var/log/messages-20150104:Dec 29 11:14:42 psp6cdatsec02 kernel: 
[1452862.786656] [ET_NET 8][23518]: segfault at 0 ip 2b91bdc1e1d8 sp 
2b91c4e080b8 error 4 in libtsutil.so.4.2.1[2b91bdbf9000+34000]
/var/log/messages-20150104:Dec 30 11:08:40 psp6cdatsec02 kernel: 
[1538932.282669] [ET_NET 27][40093]: segfault at 0 ip 2aadf5eac1d8 sp 
2aadfe41e0b8 error 4 in libtsutil.so.4.2.1[2aadf5e87000+34000]
/var/log/messages-20150104:Dec 31 11:03:58 psp6cdatsec02 kernel: 
[1625081.738033] [ET_NET 9][8107]: segfault at 0 ip 2ae1a10e81d8 sp 
2ae1a83fe0b8 error 4 in libtsutil.so.4.2.1[2ae1a10c3000+34000]
/var/log/messages-20150104:Jan  1 10:58:06 psp6cdatsec02 kernel: 
[1711161.406080] [ET_NET 2][26725]: segfault at 0 ip 2b29e35861d8 sp 
2b29ea21c0b8 error 4 in libtsutil.so.4.2.1[2b29e3561000+34000]
/var/log/messages-20150104:Jan  2 10:52:13 psp6cdatsec02 kernel: 
[1797240.486192] [ET_NET 2][43264]: segfault at 0 ip 2ae99ba081d8 sp 
2ae99e5ea0b8 error 4 in libtsutil.so.4.2.1[2ae99b9e3000+34000]
/var/log/messages-20150111:Jan  4 10:42:38 psp6cdatsec02 kernel: 
[1969528.172526] [ET_NET 8][11295]: segfault at 0 ip 2b08ce7c71d8 sp 
2b08d5a140b8 error 4 in libtsutil.so.4.2.1[2b08ce7a2000+34000]
/var/log/messages-20150111:Jan  5 10:36:36 psp6cdatsec02 kernel: 
[2055597.337456] [ET_NET 28][44084]: segfault at 0 ip 2b6fe362b1d8 sp 
2b6febc360b8 error 4 in libtsutil.so.4.2.1[2b6fe3606000+34000]
/var/log/messages-20150111:Jan  6 10:30:46 psp6cdatsec02 kernel: 
[2141679.225741] [ET_NET 2][12017]: segfault at 0 ip 2b718a2f21d8 sp 
2b7190f090b8 error 4 in libtsutil.so.4.2.1[2b718a2cd000+34000]
/var/log/messages-20150111:Jan  7 10:26:08 psp6cdatsec02 kernel: 
[2227832.753717] [ET_NET 11][28633]: segfault at 0 ip 2af8a9ccb1d8 sp 
2af8b120c0b8 error 4 in libtsutil.so.4.2.1[2af8a9ca6000+34000]
/var/log/messages-20150111:Jan  8 10:21:30 psp6cdatsec02 kernel: 
[2313986.684895] [ET_NET 12][45238]: segfault at 0 ip 2afbf62901d8 sp 
2afbfd9130b8 error 4 in libtsutil.so.4.2.1[2afbf626b000+34000]
/var/log/messages-20150111:Jan  9 10:16:53 psp6cdatsec02 kernel: 
[2400140.409556] [ET_NET 5][13212]: segfault at 0 ip 2b3d03d0c1d8 sp 
2b3d06bf10b8 error 4 in libtsutil.so.4.2.1[2b3d03ce7000+34000]
/var/log/messages-20150111:Jan 10 10:10:55 psp6cdatsec02 kernel: 
[2486214.533103] [ET_NET 26][29828]: segfault at 0 ip 2b573e8bf1d8 sp 
2b5746d270b8 error 4 in libtsutil.so.4.2.1[2b573e89a000+34000]
/var/log/messages-20150118:Jan 12 10:01:24 psp6cdatsec02 kernel: 
[2658506.193736] [ET_NET 14][46428]: segfault at 0 ip 2abd733221d8 sp 
2abd7ab250b8 error 4 in libtsutil.so.4.2.1[2abd732fd000+34000]
/var/log/messages-20150118:Jan 13 09:56:47 psp6cdatsec02 kernel: 
[2744660.662911] [ET_NET 12][30546]: segfault at 0 ip 2b5b29cf21d8 sp 
2b5b3130d0b8 error 4 in libtsutil.so.4.2.1[2b5b29ccd000+34000]
/var/log/messages-20150118:Jan 14 09:52:10 psp6cdatsec02 kernel: 

[jira] [Created] (TS-3304) segfault in libtsutsutil

2015-01-16 Thread Steve Malenfant (JIRA)
Steve Malenfant created TS-3304:
---

 Summary: segfault in libtsutsutil
 Key: TS-3304
 URL: https://issues.apache.org/jira/browse/TS-3304
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Steve Malenfant


Getting multiple segfaults per day on 4.2.1. 

[4324544.324222] [ET_NET 23][10504]: segfault at 0 ip 2acd66546168 sp 
2acd71f190b8 error 4 in libtsutil.so.4.2.1[2acd66521000+34000]
[4410696.820857] [ET_NET 19][22738]: segfault at 0 ip 2af09f339168 sp 
2af0aa9230b8 error 4 in libtsutil.so.4.2.1[2af09f314000+34000]
[4497039.474253] [ET_NET 12][34872]: segfault at 0 ip 2ad17e6a1168 sp 
2ad1896100b8 error 4 in libtsutil.so.4.2.1[2ad17e67c000+34000]
[4583372.073916] [ET_NET 3][46994]: segfault at 0 ip 2aced4227168 sp 
2aceda7d80b8 error 4 in libtsutil.so.4.2.1[2aced4202000+34000]
[4756046.944373] [ET_NET 22][10799]: segfault at 0 ip 2b1771f76168 sp 
2b177d9130b8 error 4 in libtsutil.so.4.2.1[2b1771f51000+34000]

Stack Trace :
(gdb) bt
#0  ink_inet_addr (s=value optimized out) at ink_inet.cc:107
#1  0x005e0df5 in is_dotted_form_hostname (mutex=0x1d32cb0, md5=..., 
ignore_timeout=false) at P_HostDBProcessor.h:545
#2  probe (mutex=0x1d32cb0, md5=..., ignore_timeout=false) at HostDB.cc:668
#3  0x005e2b34 in HostDBProcessor::getby (this=value optimized out, 
cont=0x2b514cc749d0, hostname=0x0, len=value optimized out, 
ip=0x2b50e8f092b0, aforce_dns=false, host_res_style=HOST_RES_NONE, 
dns_lookup_timeout=0)
at HostDB.cc:772
#4  0x00517f2c in getbyaddr_re (this=0x2b514cc749d0) at 
../../iocore/hostdb/I_HostDBProcessor.h:417
#5  HttpSM::do_hostdb_reverse_lookup (this=0x2b514cc749d0) at HttpSM.cc:3968
#6  0x0052f028 in HttpSM::set_next_state (this=0x2b514cc749d0) at 
HttpSM.cc:6932
#7  0x00518242 in HttpSM::do_hostdb_lookup (this=0x2b514cc749d0) at 
HttpSM.cc:3950
#8  0x0052f44a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
HttpSM.cc:6925
#9  0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
HttpSM.cc:1559
#10 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
HttpSM.cc:6825
#11 0x0052ea8a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
HttpSM.cc:7224
#12 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
HttpSM.cc:1559
#13 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
HttpSM.cc:6825
#14 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
HttpSM.cc:1559
#15 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
HttpSM.cc:6825
#16 0x0052fef6 in HttpSM::state_read_client_request_header 
(this=0x2b514cc749d0, event=100, data=value optimized out) at HttpSM.cc:821
#17 0x0052a5b8 in HttpSM::main_handler (this=0x2b514cc749d0, event=100, 
data=0x2b514802ca08) at HttpSM.cc:2539
#18 0x0068793b in handleEvent (event=value optimized out, 
vc=0x2b514802c900) at ../../iocore/eventsystem/I_Continuation.h:146
#19 read_signal_and_update (event=value optimized out, vc=0x2b514802c900) at 
UnixNetVConnection.cc:138
#20 0x00689ec4 in read_from_net (nh=0x2b50e2e17c10, vc=0x2b514802c900, 
thread=value optimized out) at UnixNetVConnection.cc:320
#21 0x0067fb12 in NetHandler::mainNetEvent (this=0x2b50e2e17c10, 
event=value optimized out, e=value optimized out) at UnixNet.cc:384
#22 0x006ac8cf in handleEvent (this=0x2b50e2e14010, e=0x1a9ef30, 
calling_code=5) at I_Continuation.h:146
#23 EThread::process_event (this=0x2b50e2e14010, e=0x1a9ef30, calling_code=5) 
at UnixEThread.cc:145
#24 0x006ad273 in EThread::execute (this=0x2b50e2e14010) at 
UnixEThread.cc:269
#25 0x006abc2a in spawn_thread_internal (a=0x198f820) at Thread.cc:88
#26 0x2b50e026b9d1 in start_thread () from /lib64/libpthread.so.0
#27 0x00381b2e8b6d in clone () from /lib64/libc.so.6
 



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


[jira] [Updated] (TS-3304) segfault in libtsutils

2015-01-16 Thread Steve Malenfant (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Malenfant updated TS-3304:

Summary: segfault in libtsutils  (was: segfault in libtsutsutil)

 segfault in libtsutils
 --

 Key: TS-3304
 URL: https://issues.apache.org/jira/browse/TS-3304
 Project: Traffic Server
  Issue Type: Bug
  Components: HostDB
Reporter: Steve Malenfant

 Getting multiple segfaults per day on 4.2.1. 
 [4324544.324222] [ET_NET 23][10504]: segfault at 0 ip 2acd66546168 sp 
 2acd71f190b8 error 4 in libtsutil.so.4.2.1[2acd66521000+34000]
 [4410696.820857] [ET_NET 19][22738]: segfault at 0 ip 2af09f339168 sp 
 2af0aa9230b8 error 4 in libtsutil.so.4.2.1[2af09f314000+34000]
 [4497039.474253] [ET_NET 12][34872]: segfault at 0 ip 2ad17e6a1168 sp 
 2ad1896100b8 error 4 in libtsutil.so.4.2.1[2ad17e67c000+34000]
 [4583372.073916] [ET_NET 3][46994]: segfault at 0 ip 2aced4227168 sp 
 2aceda7d80b8 error 4 in libtsutil.so.4.2.1[2aced4202000+34000]
 [4756046.944373] [ET_NET 22][10799]: segfault at 0 ip 2b1771f76168 sp 
 2b177d9130b8 error 4 in libtsutil.so.4.2.1[2b1771f51000+34000]
 Stack Trace :
 (gdb) bt
 #0  ink_inet_addr (s=value optimized out) at ink_inet.cc:107
 #1  0x005e0df5 in is_dotted_form_hostname (mutex=0x1d32cb0, md5=..., 
 ignore_timeout=false) at P_HostDBProcessor.h:545
 #2  probe (mutex=0x1d32cb0, md5=..., ignore_timeout=false) at HostDB.cc:668
 #3  0x005e2b34 in HostDBProcessor::getby (this=value optimized out, 
 cont=0x2b514cc749d0, hostname=0x0, len=value optimized out, 
 ip=0x2b50e8f092b0, aforce_dns=false, host_res_style=HOST_RES_NONE, 
 dns_lookup_timeout=0)
 at HostDB.cc:772
 #4  0x00517f2c in getbyaddr_re (this=0x2b514cc749d0) at 
 ../../iocore/hostdb/I_HostDBProcessor.h:417
 #5  HttpSM::do_hostdb_reverse_lookup (this=0x2b514cc749d0) at HttpSM.cc:3968
 #6  0x0052f028 in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6932
 #7  0x00518242 in HttpSM::do_hostdb_lookup (this=0x2b514cc749d0) at 
 HttpSM.cc:3950
 #8  0x0052f44a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6925
 #9  0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
 HttpSM.cc:1559
 #10 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6825
 #11 0x0052ea8a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:7224
 #12 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
 HttpSM.cc:1559
 #13 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6825
 #14 0x005284fa in HttpSM::handle_api_return (this=0x2b514cc749d0) at 
 HttpSM.cc:1559
 #15 0x0052ea9a in HttpSM::set_next_state (this=0x2b514cc749d0) at 
 HttpSM.cc:6825
 #16 0x0052fef6 in HttpSM::state_read_client_request_header 
 (this=0x2b514cc749d0, event=100, data=value optimized out) at HttpSM.cc:821
 #17 0x0052a5b8 in HttpSM::main_handler (this=0x2b514cc749d0, 
 event=100, data=0x2b514802ca08) at HttpSM.cc:2539
 #18 0x0068793b in handleEvent (event=value optimized out, 
 vc=0x2b514802c900) at ../../iocore/eventsystem/I_Continuation.h:146
 #19 read_signal_and_update (event=value optimized out, vc=0x2b514802c900) 
 at UnixNetVConnection.cc:138
 #20 0x00689ec4 in read_from_net (nh=0x2b50e2e17c10, 
 vc=0x2b514802c900, thread=value optimized out) at UnixNetVConnection.cc:320
 #21 0x0067fb12 in NetHandler::mainNetEvent (this=0x2b50e2e17c10, 
 event=value optimized out, e=value optimized out) at UnixNet.cc:384
 #22 0x006ac8cf in handleEvent (this=0x2b50e2e14010, e=0x1a9ef30, 
 calling_code=5) at I_Continuation.h:146
 #23 EThread::process_event (this=0x2b50e2e14010, e=0x1a9ef30, calling_code=5) 
 at UnixEThread.cc:145
 #24 0x006ad273 in EThread::execute (this=0x2b50e2e14010) at 
 UnixEThread.cc:269
 #25 0x006abc2a in spawn_thread_internal (a=0x198f820) at Thread.cc:88
 #26 0x2b50e026b9d1 in start_thread () from /lib64/libpthread.so.0
 #27 0x00381b2e8b6d in clone () from /lib64/libc.so.6
  



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