You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@trafficserver.apache.org by Mark Moseley <mo...@gmail.com> on 2013/11/22 02:33:56 UTC
Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads
> 1
I just upgraded a dev server to 4.1.1. I'm looking to do Lua-based remaps,
so I figured turning up proxy.config.remap.num_remap_threads would be good.
I was playing around with cache.config and noticed that if I have
proxy.config.remap.num_remap_threads set 8 and I try to use a url_regex in
cache.config, I get a segfault with the below stacktrace. I don't get a
segfault with proxy.config.remap.num_remap_threads=0 nor
proxy.config.remap.num_remap_threads=1 (though I thought I did see it once,
but can't replicate now). I also have no issues with
proxy.config.remap.num_remap_threads=8 but using dest_domain instead of
url_regex. ATS newbie, so expect something dumb on my part.
Incidentally, any guidance on what the appropriate value for
proxy.config.remap.num_remap_threads should be for a remap-heavy system?
Equal to # of cores?
[E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
[TrafficManager] ==> Cleaning up and reissuing signal #3
FATAL ==> [ProcessManager::pollLMConnection] Lost Manager EOF![E. Mgmt] log
==> [TrafficManager] using root directory '/usr'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x30a8203b1cb0]
/usr/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK_MD5P6HttpSM+0x52)[0x513162]
/usr/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12ContinuationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x513791]
/usr/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x528f5c]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x480)[0x529e90]
/usr/bin/traffic_server(_ZN6HttpSM22state_cache_open_writeEiPv+0x143)[0x51d5a3]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
/usr/bin/traffic_server(_ZN11HttpCacheSM22state_cache_open_writeEiPv+0x129)[0x505619]
/usr/bin/traffic_server(_ZN5Cache10open_writeEP12ContinuationP7INK_MD5P8HTTPInfolS3_13CacheFragTypePci+0x50)[0x638090]
/usr/bin/traffic_server(_ZN14CacheProcessor10open_writeEP12ContinuationiP3URLbP7HTTPHdrP8HTTPInfol13CacheFragType+0xd5)[0x609b85]
/usr/bin/traffic_server(_ZN11HttpCacheSM10open_writeEP3URLP7HTTPHdrP8HTTPInfolbb+0xa0)[0x505dd0]
/usr/bin/traffic_server(_ZN6HttpSM23do_cache_prepare_actionEP11HttpCacheSMP8HTTPInfobb+0x10b)[0x5184eb]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x5d5)[0x529fe5]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x159)[0x529b69]
/usr/bin/traffic_server(_ZN6HttpSM19state_hostdb_lookupEiPv+0xa0)[0x51b8c0]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
/usr/bin/traffic_server[0x5bb51a]
/usr/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x38d)[0x5bfbcd]
/usr/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5d27a4]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6778af]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x6e3)[0x678433]
/usr/bin/traffic_server[0x6769fa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x30a8203a9e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x30a8210caccd]
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x31ba68da0cb0]
/usr/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK_MD5P6HttpSM+0x52)[0x513162]
/usr/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12ContinuationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x513791]
/usr/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x528f5c]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x480)[0x529e90]
/usr/bin/traffic_server(_ZN6HttpSM22state_cache_open_writeEiPv+0x143)[0x51d5a3]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
/usr/bin/traffic_server(_ZN11HttpCacheSM22state_cache_open_writeEiPv+0x129)[0x505619]
/usr/bin/traffic_server(_ZN5Cache10open_writeEP12ContinuationP7INK_MD5P8HTTPInfolS3_13CacheFragTypePci+0x50)[0x638090]
/usr/bin/traffic_server(_ZN14CacheProcessor10open_writeEP12ContinuationiP3URLbP7HTTPHdrP8HTTPInfol13CacheFragType+0xd5)[0x609b85]
/usr/bin/traffic_server(_ZN11HttpCacheSM10open_writeEP3URLP7HTTPHdrP8HTTPInfolbb+0xa0)[0x505dd0]
/usr/bin/traffic_server(_ZN6HttpSM23do_cache_prepare_actionEP11HttpCacheSMP8HTTPInfobb+0x10b)[0x5184eb]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x5d5)[0x529fe5]
/usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x159)[0x529b69]
/usr/bin/traffic_server(_ZN6HttpSM19state_hostdb_lookupEiPv+0xa0)[0x51b8c0]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
/usr/bin/traffic_server[0x5bb51a]
/usr/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x38d)[0x5bfbcd]
/usr/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5d27a4]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6778af]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x6e3)[0x678433]
/usr/bin/traffic_server[0x6769fa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x31ba68d98e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x31ba69ab9ccd]
Re: Segfault with 4.1.1 using url_regex and
proxy.config.remap.num_remap_threads > 1
Posted by Igor Galić <i....@brainsware.org>.
> > Where would be a good place to put this piece of wisdom as documentation?
>
> > I think we need to start a performance tuning doc that'll show admins which
> > knobs to turn to actually get out a better performance.
>
> +1.
> Lets add a section to the admin guide, that we can start filling out. As per
> normal inertia / resistance, someone has to start it and do the initial
> layout.
Done, TS-2394
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads > 1
Posted by Leif Hedstrom <zw...@apache.org>.
On Nov 25, 2013, at 9:34 AM, Igor Galić <i....@brainsware.org> wrote:
>
>
> Out of curiosity, why are you using the remap threads? Do you have a remap plugin that can block ?
>
> Nope, just will be doing high volume, Lua-based remapping, so that sounded like it could be a useful setting. But sounds like I don't need it, since my Lua code never blocks.
>
> Yeah try without it first. If you experience unacceptable latencies, increase the number of worker threads first. That will give you more Lua states as well.
> Where would be a good place to put this piece of wisdom as documentation?
>
> I think we need to start a performance tuning doc that'll show admins which knobs to turn to actually get out a better performance.
+1.
Lets add a section to the admin guide, that we can start filling out. As per normal inertia / resistance, someone has to start it and do the initial layout.
Cheers,
— Leif
Re: Segfault with 4.1.1 using url_regex and
proxy.config.remap.num_remap_threads > 1
Posted by Igor Galić <i....@brainsware.org>.
> > > Out of curiosity, why are you using the remap threads? Do you have a
> > > remap
> > > plugin that can block ?
> >
>
> > Nope, just will be doing high volume, Lua-based remapping, so that sounded
> > like it could be a useful setting. But sounds like I don't need it, since
> > my
> > Lua code never blocks.
>
> Yeah try without it first. If you experience unacceptable latencies, increase
> the number of worker threads first. That will give you more Lua states as
> well.
Where would be a good place to put this piece of wisdom as documentation?
I think we need to start a performance tuning doc that'll show admins which knobs to turn to actually get out a better performance.
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads > 1
Posted by Leif Hedstrom <zw...@apache.org>.
> On Nov 23, 2013, at 12:15 AM, Mark Moseley <mo...@gmail.com> wrote:
>
>> On Fri, Nov 22, 2013 at 7:49 PM, Leif Hedstrom <zw...@apache.org> wrote:
>>
>> On Nov 21, 2013, at 8:56 PM, James Peach <jp...@apache.org> wrote:
>>
>> > On Nov 21, 2013, at 7:43 PM, Mark Moseley <mo...@gmail.com> wrote:
>> >
>> >> On Thu, Nov 21, 2013 at 5:57 PM, Thomas Berger <th...@it.piratenpartei.de> wrote:
>> >> I could not reproduce this issue. Could you please post an example of the
>> >> regex causing this segfault?
>> >>
>> >> Also, even if there would be some configuration errors on your part, ATS should
>> >> thrown an error, not a stack trace. So would file a bug at
>>
>>
>> I’m fairly certain this is a duplicate of TS-1590 and to some extent TS-1666. I closed this one as a duplicate of TS-1590.
>>
>> Out of curiosity, why are you using the remap threads? Do you have a remap plugin that can block ?
>
> Nope, just will be doing high volume, Lua-based remapping, so that sounded like it could be a useful setting. But sounds like I don't need it, since my Lua code never blocks.
Yeah try without it first. If you experience unacceptable latencies, increase the number of worker threads first. That will give you more Lua states as well.
Cheers,
-- Leif
>
> Thanks!
>
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads
> 1
Posted by Mark Moseley <mo...@gmail.com>.
On Fri, Nov 22, 2013 at 7:49 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
> On Nov 21, 2013, at 8:56 PM, James Peach <jp...@apache.org> wrote:
>
> > On Nov 21, 2013, at 7:43 PM, Mark Moseley <mo...@gmail.com> wrote:
> >
> >> On Thu, Nov 21, 2013 at 5:57 PM, Thomas Berger <
> th.berger@it.piratenpartei.de> wrote:
> >> I could not reproduce this issue. Could you please post an example of
> the
> >> regex causing this segfault?
> >>
> >> Also, even if there would be some configuration errors on your part,
> ATS should
> >> thrown an error, not a stack trace. So would file a bug at
>
>
> I’m fairly certain this is a duplicate of TS-1590 and to some extent
> TS-1666. I closed this one as a duplicate of TS-1590.
>
> Out of curiosity, why are you using the remap threads? Do you have a remap
> plugin that can block ?
>
Nope, just will be doing high volume, Lua-based remapping, so that sounded
like it could be a useful setting. But sounds like I don't need it, since
my Lua code never blocks.
Thanks!
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads > 1
Posted by Leif Hedstrom <zw...@apache.org>.
On Nov 21, 2013, at 8:56 PM, James Peach <jp...@apache.org> wrote:
> On Nov 21, 2013, at 7:43 PM, Mark Moseley <mo...@gmail.com> wrote:
>
>> On Thu, Nov 21, 2013 at 5:57 PM, Thomas Berger <th...@it.piratenpartei.de> wrote:
>> I could not reproduce this issue. Could you please post an example of the
>> regex causing this segfault?
>>
>> Also, even if there would be some configuration errors on your part, ATS should
>> thrown an error, not a stack trace. So would file a bug at
I’m fairly certain this is a duplicate of TS-1590 and to some extent TS-1666. I closed this one as a duplicate of TS-1590.
Out of curiosity, why are you using the remap threads? Do you have a remap plugin that can block ?
Cheers,
— leif
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads
> 1
Posted by Mark Moseley <mo...@gmail.com>.
Opened https://issues.apache.org/jira/browse/TS-2388
On Thu, Nov 21, 2013 at 7:56 PM, James Peach <jp...@apache.org> wrote:
> On Nov 21, 2013, at 7:43 PM, Mark Moseley <mo...@gmail.com> wrote:
>
> > On Thu, Nov 21, 2013 at 5:57 PM, Thomas Berger <
> th.berger@it.piratenpartei.de> wrote:
> > I could not reproduce this issue. Could you please post an example of the
> > regex causing this segfault?
> >
> > Also, even if there would be some configuration errors on your part, ATS
> should
> > thrown an error, not a stack trace. So would file a bug at
> >
> > https://issues.apache.org/jira/browse/TS
> >
> >
> >
> > I tried with both:
> > url_regex=.
> > and
> > url_regex=/
> >
> > (Wanted a wildcard, but dest_domain=. seems to work ok too)
> >
> > I can open a ticket. I just wanted to see if it was me doing something
> stupid before opening an erroneous ticket.
>
> The closest ticket I could find was
> https://issues.apache.org/jira/browse/TS-1590. I agree with Thomas;
> please open a new ticket. If it the same issue we will just mark it as a
> duplicate ...
>
> J
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads > 1
Posted by James Peach <jp...@apache.org>.
On Nov 21, 2013, at 7:43 PM, Mark Moseley <mo...@gmail.com> wrote:
> On Thu, Nov 21, 2013 at 5:57 PM, Thomas Berger <th...@it.piratenpartei.de> wrote:
> I could not reproduce this issue. Could you please post an example of the
> regex causing this segfault?
>
> Also, even if there would be some configuration errors on your part, ATS should
> thrown an error, not a stack trace. So would file a bug at
>
> https://issues.apache.org/jira/browse/TS
>
>
>
> I tried with both:
> url_regex=.
> and
> url_regex=/
>
> (Wanted a wildcard, but dest_domain=. seems to work ok too)
>
> I can open a ticket. I just wanted to see if it was me doing something stupid before opening an erroneous ticket.
The closest ticket I could find was https://issues.apache.org/jira/browse/TS-1590. I agree with Thomas; please open a new ticket. If it the same issue we will just mark it as a duplicate ...
J
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads
> 1
Posted by Mark Moseley <mo...@gmail.com>.
On Thu, Nov 21, 2013 at 5:57 PM, Thomas Berger <
th.berger@it.piratenpartei.de> wrote:
> I could not reproduce this issue. Could you please post an example of the
> regex causing this segfault?
>
> Also, even if there would be some configuration errors on your part, ATS
> should
> thrown an error, not a stack trace. So would file a bug at
>
> https://issues.apache.org/jira/browse/TS
>
>
>
I tried with both:
url_regex=.
and
url_regex=/
(Wanted a wildcard, but dest_domain=. seems to work ok too)
I can open a ticket. I just wanted to see if it was me doing something
stupid before opening an erroneous ticket.
Re: Segfault with 4.1.1 using url_regex and proxy.config.remap.num_remap_threads > 1
Posted by Thomas Berger <th...@it.piratenpartei.de>.
I could not reproduce this issue. Could you please post an example of the
regex causing this segfault?
Also, even if there would be some configuration errors on your part, ATS should
thrown an error, not a stack trace. So would file a bug at
https://issues.apache.org/jira/browse/TS
Am Donnerstag, 21. November 2013, 17:33:56 schrieb Mark Moseley:
> I just upgraded a dev server to 4.1.1. I'm looking to do Lua-based remaps,
> so I figured turning up proxy.config.remap.num_remap_threads would be good.
> I was playing around with cache.config and noticed that if I have
> proxy.config.remap.num_remap_threads set 8 and I try to use a url_regex in
> cache.config, I get a segfault with the below stacktrace. I don't get a
> segfault with proxy.config.remap.num_remap_threads=0 nor
> proxy.config.remap.num_remap_threads=1 (though I thought I did see it once,
> but can't replicate now). I also have no issues with
> proxy.config.remap.num_remap_threads=8 but using dest_domain instead of
> url_regex. ATS newbie, so expect something dumb on my part.
>
> Incidentally, any guidance on what the appropriate value for
> proxy.config.remap.num_remap_threads should be for a remap-heavy system?
> Equal to # of cores?
>
>
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> [TrafficManager] ==> Cleaning up and reissuing signal #3
> FATAL ==> [ProcessManager::pollLMConnection] Lost Manager EOF![E. Mgmt] log
> ==> [TrafficManager] using root directory '/usr'
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x30a8203b1cb0]
> /usr/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK
> _MD5P6HttpSM+0x52)[0x513162]
> /usr/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12Continu
> ationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x513791]
> /usr/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x528f5c]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x480)[0x529e90]
> /usr/bin/traffic_server(_ZN6HttpSM22state_cache_open_writeEiPv+0x143)[0x51d
> 5a3] /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
> /usr/bin/traffic_server(_ZN11HttpCacheSM22state_cache_open_writeEiPv+0x129)
> [0x505619]
> /usr/bin/traffic_server(_ZN5Cache10open_writeEP12ContinuationP7INK_MD5P8HTT
> PInfolS3_13CacheFragTypePci+0x50)[0x638090]
> /usr/bin/traffic_server(_ZN14CacheProcessor10open_writeEP12ContinuationiP3U
> RLbP7HTTPHdrP8HTTPInfol13CacheFragType+0xd5)[0x609b85]
> /usr/bin/traffic_server(_ZN11HttpCacheSM10open_writeEP3URLP7HTTPHdrP8HTTPIn
> folbb+0xa0)[0x505dd0]
> /usr/bin/traffic_server(_ZN6HttpSM23do_cache_prepare_actionEP11HttpCacheSMP
> 8HTTPInfobb+0x10b)[0x5184eb]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x5d5)[0x529fe5]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x159)[0x529b69]
> /usr/bin/traffic_server(_ZN6HttpSM19state_hostdb_lookupEiPv+0xa0)[0x51b8c0]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
> /usr/bin/traffic_server[0x5bb51a]
> /usr/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x38d)[0
> x5bfbcd]
> /usr/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5d27a4]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6778af]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x6e3)[0x678433]
> /usr/bin/traffic_server[0x6769fa]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x30a8203a9e9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x30a8210caccd]
> [TrafficServer] using root directory '/usr'
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /usr/bin/traffic_server - STACK TRACE:
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0)[0x31ba68da0cb0]
> /usr/bin/traffic_server(_Z16_acquire_sessionP13SessionBucketPK8sockaddrR7INK
> _MD5P6HttpSM+0x52)[0x513162]
> /usr/bin/traffic_server(_ZN18HttpSessionManager15acquire_sessionEP12Continu
> ationPK8sockaddrPKcP17HttpClientSessionP6HttpSM+0x3d1)[0x513791]
> /usr/bin/traffic_server(_ZN6HttpSM19do_http_server_openEb+0x30c)[0x528f5c]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x480)[0x529e90]
> /usr/bin/traffic_server(_ZN6HttpSM22state_cache_open_writeEiPv+0x143)[0x51d
> 5a3] /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
> /usr/bin/traffic_server(_ZN11HttpCacheSM22state_cache_open_writeEiPv+0x129)
> [0x505619]
> /usr/bin/traffic_server(_ZN5Cache10open_writeEP12ContinuationP7INK_MD5P8HTT
> PInfolS3_13CacheFragTypePci+0x50)[0x638090]
> /usr/bin/traffic_server(_ZN14CacheProcessor10open_writeEP12ContinuationiP3U
> RLbP7HTTPHdrP8HTTPInfol13CacheFragType+0xd5)[0x609b85]
> /usr/bin/traffic_server(_ZN11HttpCacheSM10open_writeEP3URLP7HTTPHdrP8HTTPIn
> folbb+0xa0)[0x505dd0]
> /usr/bin/traffic_server(_ZN6HttpSM23do_cache_prepare_actionEP11HttpCacheSMP
> 8HTTPInfobb+0x10b)[0x5184eb]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x5d5)[0x529fe5]
> /usr/bin/traffic_server(_ZN6HttpSM14set_next_stateEv+0x159)[0x529b69]
> /usr/bin/traffic_server(_ZN6HttpSM19state_hostdb_lookupEiPv+0xa0)[0x51b8c0]
> /usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x78)[0x524d98]
> /usr/bin/traffic_server[0x5bb51a]
> /usr/bin/traffic_server(_ZN18HostDBContinuation8dnsEventEiP7HostEnt+0x38d)[0
> x5bfbcd]
> /usr/bin/traffic_server(_ZN8DNSEntry9postEventEiP5Event+0x44)[0x5d27a4]
> /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x6778af]
> /usr/bin/traffic_server(_ZN7EThread7executeEv+0x6e3)[0x678433]
> /usr/bin/traffic_server[0x6769fa]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x31ba68d98e9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x31ba69ab9ccd]
--
Mit freundlichen Grüßen,
Thomas Berger
Piraten IT
--
Piratenpartei Deutschland - Pirate Party of Germany
Pflugstraße 9a, D-10115 Berlin, Germany
Vorstand: Bernd Schlömer, Sebastian Nerz, Markus Barenhoff, Swanhild
Goetze, Sven Schomacker, Katharina Nocun, Klaus Peukert,
Christophe Chan Hin, Andi Popp