You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Bryan Call (JIRA)" <ji...@apache.org> on 2016/11/03 22:07:00 UTC

[jira] [Comment Edited] (TS-4994) PANIC: unprotected error in call to Lua API (not enough memory)

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

Bryan Call edited comment on TS-4994 at 11/3/16 10:06 PM:
----------------------------------------------------------

[~kichan] [~ftarnell]
Is this going to be an issue in the ATS 7.0.0 release?  Do we need to get this fixed and backport it?


was (Author: bcall):
[~kichan] [~ftarnell]
Is this going to be an issue in the ATS 7.0.0 release?  Do we need to get this fix and backport it?

> PANIC: unprotected error in call to Lua API (not enough memory)
> ---------------------------------------------------------------
>
>                 Key: TS-4994
>                 URL: https://issues.apache.org/jira/browse/TS-4994
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Lua
>    Affects Versions: 6.2.0
>            Reporter: Felicity Tarnell
>            Assignee: Kit Chan
>             Fix For: 7.1.0
>
>
> We have a working installation of TS 6.1; when upgrading to 6.2, it repeatedly crashes almost immediately after startup with:
> {noformat}
> PANIC: unprotected error in call to Lua API (not enough memory)
> pure virtual method called
> terminate called without an active exception
> traffic_server: using root directory '/opt/tbx'
> traffic_server: Aborted (Signal sent by tkill() 11964 33)
> traffic_server - STACK TRACE: 
> /opt/tbx/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ac16e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0)[0x2b2c43b828d0]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2b2c44b52067]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2b2c44b53448]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(_ZN9__gnu_cxx27__verbose_terminate_handlerEv+0x15d)[0x2b2c4435bb3d]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ebb6)[0x2b2c44359bb6]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5ec01)[0x2b2c44359c01]
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6(+0x5f6cf)[0x2b2c4435a6cf]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept18do_blocking_acceptEP7EThread+0x99)[0x74dd69]
> /opt/tbx/bin/traffic_server(_ZN9NetAccept15acceptLoopEventEiP5Event+0x2b)[0x74e62b]
> /opt/tbx/bin/traffic_server(_ZN7EThread7executeEv+0x7f)[0x77ce1f]
> /opt/tbx/bin/traffic_server[0x77c315]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x80a4)[0x2b2c43b7b0a4]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2b2c44c0587d]
> {noformat}
> We have about 5000 lines of Lua, and one C module (lualdap), but nothing that should be approaching Lua's memory limit; it's mostly just access checks that don't allocate any memory at all.



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