[jira] [Commented] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192190#comment-13192190 ] Leif Hedstrom commented on TS-1083: --- Quick question: when I first looked at this, my code simply did #ifdef OPENSSL_NPN_NEGOTIATED Is there a reason we have to have autoconf check for NPN support? Is there ever a reason not to support NPN (even with just HTTPS) if the OpenSSL library has it available? initial SSL next protocol negotiation support - Key: TS-1083 URL: https://issues.apache.org/jira/browse/TS-1083 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Attachments: 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, 0002-Initial-NPN-plumbing.patch Initial autoconf support for detecting OpenSSL Next Protocol Negotiation APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192268#comment-13192268 ] James Peach commented on TS-1083: - Ah, I just didn't notice that there was a OPENSSL_NPN_NEGOTIATED. If I had I would not have bothered with the autoconf checks. initial SSL next protocol negotiation support - Key: TS-1083 URL: https://issues.apache.org/jira/browse/TS-1083 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Attachments: 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, 0002-Initial-NPN-plumbing.patch Initial autoconf support for detecting OpenSSL Next Protocol Negotiation APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1083) initial SSL next protocol negotiation support
[ https://issues.apache.org/jira/browse/TS-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192288#comment-13192288 ] Leif Hedstrom commented on TS-1083: --- Well, that's one #define available in OpenSSL when NPN is available. I have no problems with your patch, so just decide which route you think we should go. I picked OPENSSL_NPN_NEGOTIATED, because I saw other solutions doing the same :). initial SSL next protocol negotiation support - Key: TS-1083 URL: https://issues.apache.org/jira/browse/TS-1083 Project: Traffic Server Issue Type: Improvement Components: SSL Reporter: James Peach Assignee: Leif Hedstrom Priority: Minor Attachments: 0001-Compile-time-detection-of-NextProtocolNegotiation-su.patch, 0002-Initial-NPN-plumbing.patch Initial autoconf support for detecting OpenSSL Next Protocol Negotiation APIs. Advertise that we support HTTP/1.0 and HTTP/1.1. Because we do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1091:
--
Fix Version/s: 3.1.2
Assignee: Leif Hedstrom
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Assignee: Leif Hedstrom
Priority: Minor
Labels: autoconf, build, configure
Fix For: 3.1.2
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1085) traffic_shell enable command doesn't work
[ https://issues.apache.org/jira/browse/TS-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1085: -- Fix Version/s: 3.1.3 Assignee: James Peach Moving out to 3.1.3, move back to 3.1.2 if you'll get this done this week. traffic_shell enable command doesn't work - Key: TS-1085 URL: https://issues.apache.org/jira/browse/TS-1085 Project: Traffic Server Issue Type: Bug Components: Management Reporter: James Peach Assignee: James Peach Fix For: 3.1.3 Let's try this as root: blacko:trafficserver.git jpeach$ sudo /opt/ats/bin/traffic_shell Successfully Initialized MgmtAPI in /opt/ats/var/trafficserver % trafficserver enable Already Enabled trafficserver exit Ok, to let's try as non-root: blacko:trafficserver.git jpeach$ /opt/ats/bin/traffic_shell [connect] ERROR (main_socket_fd 3): Permission denied TSInit 5: Failed to initialize MgmtAPI in /opt/ats/var/trafficserver [connect] ERROR (main_socket_fd 3): Permission denied % trafficserver enable FATAL: ConfigCmd.cc:137: failed assert `enable_restricted_commands` /opt/ats/bin/traffic_shell - STACK TRACE: 0 libtsutil.3.dylib 0x00010cec8b8b ink_fatal_va + 283 1 libtsutil.3.dylib 0x00010cec8e94 ink_fatal + 356 2 libtsutil.3.dylib 0x00010cec66ff _ink_assert + 271 3 traffic_shell 0x00010ce253ab _Z10Cmd_EnablePvP10Tcl_InterpiPPKc + 395 4 Tcl 0x00010cf34261 TclInvokeStringCommand + 121 5 Tcl 0x00010cf360b7 Tcl_GetMathFuncInfo + 2533 6 Tcl 0x00010cf36d14 Tcl_GetMathFuncInfo + 5698 7 Tcl 0x00010cf370d2 Tcl_Eval + 42 So either enable does nothing or it crashes. Seems like we should fix or remove this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: (was: ts-1077.diff) HTTP ports cannot be configured for IPv6 and transparency. -- Key: TS-1077 URL: https://issues.apache.org/jira/browse/TS-1077 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: configuration, http, ipv6, ports Fix For: 3.1.3 The syntax of records.config has IPv6 and transparency as mutually exclusive options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: ts-1077.diff SSL fixed. if ssl.enable and ssl.server_port are set, those are used to create an SSL port. If ssl.enable is set then an SSL port is forced, using ssl.server_port if available and 443 if not. If an SSL port is set in http.server_ports that is used regardless of ssl.enable. HTTP ports cannot be configured for IPv6 and transparency. -- Key: TS-1077 URL: https://issues.apache.org/jira/browse/TS-1077 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: configuration, http, ipv6, ports Fix For: 3.1.3 Attachments: ts-1077.diff The syntax of records.config has IPv6 and transparency as mutually exclusive options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-1035) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults
[ https://issues.apache.org/jira/browse/TS-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-1035: Assignee: Brian Geffon (was: Leif Hedstrom) EventProcessor::spawn_thread doesn't check that there is enough event threads and segfaults --- Key: TS-1035 URL: https://issues.apache.org/jira/browse/TS-1035 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.0.1 Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.1.3 Attachments: LargeNumberOfPorts.patch, UnixEventProcessor.patch The easiest way to see this bug is to use several hundred ports with accept threads turned on. The bug exists because in I_EventProcessor.h there is a hard coded limit of 512 event threads and there is no check in spawn_thread that you haven't exceeded that limit so it will result in a segfault if you're creating too many threads. From what I can tell the best solution is an assertion that you haven't exceeded MAX_EVENT_THREADS. Patch is included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192389#comment-13192389 ] Igor Galić commented on TS-1077: Can you please update the admin docs as well? Or tell one of our minions if you can't. HTTP ports cannot be configured for IPv6 and transparency. -- Key: TS-1077 URL: https://issues.apache.org/jira/browse/TS-1077 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: configuration, http, ipv6, ports Fix For: 3.1.3 Attachments: ts-1077.diff The syntax of records.config has IPv6 and transparency as mutually exclusive options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1079) Add an API function to turn debugging on for specific transactions/sessions
[ https://issues.apache.org/jira/browse/TS-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192465#comment-13192465 ] Leif Hedstrom commented on TS-1079: --- The patch looks good to me. And yes, I agree, we require gcc (or compatible) 4.1 I think (to simplify atomic support). I'm fine with cleanup (getting rid of old crud is good). I'm assuming the next step is for you to change some (select) Debug() invocations in the core? How do you plan to decide which ones are useful or not? Add an API function to turn debugging on for specific transactions/sessions --- Key: TS-1079 URL: https://issues.apache.org/jira/browse/TS-1079 Project: Traffic Server Issue Type: Improvement Components: Core, HTTP Reporter: Uri Shachar Priority: Minor Attachments: debug_specific.patch Original Estimate: 72h Remaining Estimate: 72h When attempting to troubleshoot issues on a production ATS system, it is often impossible/difficult to turn on any of the 'high-volume' debug tags like http due to the performance impact. This enhancement allows a plugin to set a debug flag for a specific txn/ssn, and replaces some of the internal Debug calls with a new function that checks if the flag is turned on, and outputs the debug line regardless of the tag if it is (The diags enable/disable flag is still taken into account). The API will also have TSDebugSpecific in order to allow plugins to use the same functionality. In addition, we might consider adding an internal config file (remap-like) to allow turning this flag on without plugin intervention. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1017) Upgrade LogHost / LogSock to IPv6.
[ https://issues.apache.org/jira/browse/TS-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192801#comment-13192801 ] Alan M. Carroll commented on TS-1017: - I have this almost entirely coded, primarily need some testing. Upgrade LogHost / LogSock to IPv6. -- Key: TS-1017 URL: https://issues.apache.org/jira/browse/TS-1017 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 3.0.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 3.1.3 Remote logging should be able to work on IPv6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TS-693) Automatic Navigation links should point at the EN version if the current language isn't available.
[ https://issues.apache.org/jira/browse/TS-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll resolved TS-693. Resolution: Fixed This was fixed during the last auto-navigation update. Automatic Navigation links should point at the EN version if the current language isn't available. -- Key: TS-693 URL: https://issues.apache.org/jira/browse/TS-693 Project: Traffic Server Issue Type: Bug Components: Documentation Affects Versions: 2.1.7 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Priority: Minor Fix For: Doc 3.0 If we have a page in the documentation that available in a non-EN language (e.g. ZW), then where should the generated Next/Back links point if there is not a ZW version of those targets? Currently they aren't available. Instead, the links should point at the EN version if the same language target doesn't exist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1017) Upgrade LogHost / LogSock to IPv6.
[ https://issues.apache.org/jira/browse/TS-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1017: Fix Version/s: (was: 3.1.2) 3.1.3 Upgrade LogHost / LogSock to IPv6. -- Key: TS-1017 URL: https://issues.apache.org/jira/browse/TS-1017 Project: Traffic Server Issue Type: Improvement Components: Logging Affects Versions: 3.0.0 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Fix For: 3.1.3 Remote logging should be able to work on IPv6. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-295) Allowing HTTP CONNECT to be used on non-SSL ports
[ https://issues.apache.org/jira/browse/TS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13192805#comment-13192805 ] Alan M. Carroll commented on TS-295: This should be re-examined after TS-1077 is committed as it will make the configuration side much easier. Allowing HTTP CONNECT to be used on non-SSL ports - Key: TS-295 URL: https://issues.apache.org/jira/browse/TS-295 Project: Traffic Server Issue Type: Improvement Components: Documentation Affects Versions: 2.0.0 Environment: All? Reporter: Marcus Clyne Priority: Minor Fix For: Doc 3.0 Attachments: TS-295.diff Currently HTTP CONNECT can only be used on ports designated as SSL ports in the config file, even if SSL is not used. It seems more sensible to add a config option to specify which ports can be tunneled through using CONNECT's, perhaps defaulting to the SSL ports, but not being limited to them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-935) Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT
[ https://issues.apache.org/jira/browse/TS-935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-935: --- Fix Version/s: (was: 3.1.2) 3.1.3 Should EVENT_INTERNAL really be the same as TS_EVENT_TIMEOUT Key: TS-935 URL: https://issues.apache.org/jira/browse/TS-935 Project: Traffic Server Issue Type: Bug Components: TS API Affects Versions: 3.0.1 Reporter: Brian Geffon Fix For: 3.1.3 When trying to use TSContCall with event = TS_EVENT_TIMEOUT I stumbled upon the fact that the API will decrement the event count for EVENT_INTERNAL or EVENT_IMMEDIATE (see INKContInternal::handle_event_count), but shouldn't we be able to do a TSContCall with TS_EVENT_IMMEDIAITE or TS_EVENT_TIMEOUT because as of now doing so would cause m_event_count to become -1 or shouldn't these defined values be something different? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Fix Version/s: (was: 3.1.3) 3.1.2 HTTP ports cannot be configured for IPv6 and transparency. -- Key: TS-1077 URL: https://issues.apache.org/jira/browse/TS-1077 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: configuration, http, ipv6, ports Fix For: 3.1.2 Attachments: ts-1077.diff The syntax of records.config has IPv6 and transparency as mutually exclusive options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-937) EThread::execute still processing cancelled event
[
https://issues.apache.org/jira/browse/TS-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-937:
---
Fix Version/s: (was: 3.1.2)
3.1.3
EThread::execute still processing cancelled event
-
Key: TS-937
URL: https://issues.apache.org/jira/browse/TS-937
Project: Traffic Server
Issue Type: Bug
Components: Core
Affects Versions: 3.0.1, 2.1.9
Environment: RHEL6
Reporter: Brian Geffon
Assignee: Brian Geffon
Fix For: 3.1.3
Attachments: UnixEThread.patch
The included GDB log will show that ATS is trying to process an event that
has already been canceled, examining the code of UnixEThread.cc line 232
shows that EThread::process_event gets called without a check for the event
being cancelled.
Brian
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x764fa700 (LWP 28518)]
0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
Missing separate debuginfos, use: debuginfo-install
expat-2.0.1-9.1.el6.x86_64 glibc-2.12-1.25.el6_1.3.x86_64
keyutils-libs-1.4-1.el6.x86_64 krb5-libs-1.9-9.el6_1.1.x86_64
libcom_err-1.41.12-7.el6.x86_64 libgcc-4.4.5-6.el6.x86_64
libselinux-2.0.94-5.el6.x86_64 libstdc++-4.4.5-6.el6.x86_64
openssl-1.0.0-10.el6_1.4.x86_64 pcre-7.8-3.1.el6.x86_64
tcl-8.5.7-6.el6.x86_64 zlib-1.2.3-25.el6.x86_64
(gdb) bt
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
(gdb) bt full
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
lock = {m = {m_ptr = 0x764f9d20}, lock_acquired = 202}
#1 0x006fcbaf in EThread::execute (this=0x768ff010) at
UnixEThread.cc:232
done_one = false
e = 0x1db45c0
NegativeQueue = {DLLEvent, Event::Link_link = {head = 0xfc75f0},
tail = 0xfc75f0}
next_time = 1314647904419648000
#2 0x006fb844 in spawn_thread_internal (a=0xfb7e80) at Thread.cc:88
p = 0xfb7e80
#3 0x0036204077e1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00361f8e577d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb) f 0
#0 0x006fc663 in EThread::process_event (this=0x768ff010,
e=0x1db45c0, calling_code=1) at UnixEThread.cc:130
130 MUTEX_TRY_LOCK_FOR(lock, e-mutex.m_ptr, this, e-continuation);
(gdb) p *e
$2 = {Action = {_vptr.Action = 0x775170, continuation = 0x1f2fc08, mutex =
{m_ptr = 0x7fffd40fba40}, cancelled = 1}, ethread = 0x768ff010,
in_the_prot_queue = 0, in_the_priority_queue = 0,
immediate = 1, globally_allocated = 1, in_heap = 0, callback_event = 1,
timeout_at = 0, period = 0, cookie = 0x0, link = {SLinkEvent = {next =
0x0}, prev = 0x0}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
