[
https://issues.apache.org/jira/browse/TS-3235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14287179#comment-14287179
]
zouyu commented on TS-3235:
---------------------------
@portl4t,
One more question about holding the lock of continuation before performing task
in customer threads,
if so, should we move the lock into 'TS' API? such as TSVIOReenable,
TSVConnClose?
For continuation, customer can get the lock because when he wants to create a
continuation, he must create the related mutex, but for 'VC', how the customer
can get the related mutex from it directly? since ATS already hide the inner
objects from customers.
For example, if we want to call TSVConnClose, we need to get the lock of the
'VC', but how to get it directly? Seems no API to do it.
And also for TSVIOReenable, if the customer doesn't check the code that "vio's
mutex = cont's mutex",
how he can get the vio's mutex?
> PluginVC crashed with unrecognized event
> ----------------------------------------
>
> Key: TS-3235
> URL: https://issues.apache.org/jira/browse/TS-3235
> Project: Traffic Server
> Issue Type: Bug
> Components: CPP API, HTTP, Plugins
> Reporter: kang li
> Assignee: Brian Geffon
> Fix For: 5.3.0
>
> Attachments: pluginvc-crash.diff
>
>
> We are using atscppapi to create Intercept plugin.
>
> From the coredump , that seems Continuation of the InterceptPlugin was
> already been destroyed.
> {code}
> #0 0x000000375ac32925 in raise () from /lib64/libc.so.6
> #1 0x000000375ac34105 in abort () from /lib64/libc.so.6
> #2 0x00002b21eeae3458 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x00002b21eeae3525 in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1,
> message_format=0x2b21eeaf08d8 "%s:%d: failed assert `%s`",
> ap=0x2b21f4913ad0) at ink_error.cc:65
> #4 0x00002b21eeae35ee in ink_fatal (return_code=1,
> message_format=0x2b21eeaf08d8 "%s:%d: failed assert `%s`") at ink_error.cc:73
> #5 0x00002b21eeae2160 in _ink_assert (expression=0x76ddb8 "call_event ==
> core_lock_retry_event", file=0x76dd04 "PluginVC.cc", line=203)
> at ink_assert.cc:37
> #6 0x0000000000530217 in PluginVC::main_handler (this=0x2b24ef007cb8,
> event=1, data=0xe0f5b80) at PluginVC.cc:203
> #7 0x00000000004f5854 in Continuation::handleEvent (this=0x2b24ef007cb8,
> event=1, data=0xe0f5b80) at ../iocore/eventsystem/I_Continuation.h:146
> #8 0x0000000000755d26 in EThread::process_event (this=0x309b250,
> e=0xe0f5b80, calling_code=1) at UnixEThread.cc:145
> #9 0x000000000075610a in EThread::execute (this=0x309b250) at
> UnixEThread.cc:239
> #10 0x0000000000755284 in spawn_thread_internal (a=0x2849330) at Thread.cc:88
> #11 0x00002b21ef05f9d1 in start_thread () from /lib64/libpthread.so.0
> #12 0x000000375ace8b7d in clone () from /lib64/libc.so.6
> (gdb) p sm_lock_retry_event
> $13 = (Event *) 0x2b2496146e90
> (gdb) p core_lock_retry_event
> $14 = (Event *) 0x0
> (gdb) p active_event
> $15 = (Event *) 0x0
> (gdb) p inactive_event
> $16 = (Event *) 0x0
> (gdb) p *(INKContInternal*)this->core_obj->connect_to
> Cannot access memory at address 0x2b269cd46c10
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
