[Bug 53469] possible bug in Response.normalize(CharChunk cc)
https://issues.apache.org/bugzilla/show_bug.cgi?id=53469 --- Comment #12 from papegaaij emond.papega...@topicus.nl --- In my opinion, Tomcat should not convert relative URLs to absolute in encodeURL. That should only be done in encodeRedirectURL. encodeURL can still perform normalization, as long as it preserves relative URLs. For example, ./a/../b can be normalized to ./b, but it should not be converted into an absolute URL. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53469] possible bug in Response.normalize(CharChunk cc)
https://issues.apache.org/bugzilla/show_bug.cgi?id=53469 --- Comment #13 from mgrigorov mgrigo...@apache.org --- I agree with Emond. By Servlet spec (actually the javadoc of javax.servlet.http.HttpServletResponse#sendRedirect) only #sendRedirect() should convert the url from relative to absolute. I think this is the place where URL normalization should happen. Using HttpServletRequestWrapper in Wicket in an option but this will solve the problem only in Wicket. Every other framework or plain application may face the same problem. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 5.5.36
On Jul 24, 2012, at 12:17 PM, Mark Thomas wrote: On 24/07/2012 14:40, Jim Jagielski wrote: Any interest in seeing a 5.5.36 release in the near future? We should to tie up the remaining loose ends before 5.5.x is EOL. No great rush at the moment though. Yeah, that's my plan. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53601] New: tomcat7 build fails with jdk1.6
https://issues.apache.org/bugzilla/show_bug.cgi?id=53601 Priority: P2 Bug ID: 53601 Assignee: dev@tomcat.apache.org Summary: tomcat7 build fails with jdk1.6 Severity: normal Classification: Unclassified Reporter: strub...@yahoo.de Hardware: PC Status: NEW Version: trunk Component: Catalina Product: Tomcat 7 Currently tomcat7 can only be build with jdk1.7. That might become a problem as Servlet-3.0 mandatory requires java6 as environment. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53601] tomcat7 build fails with jdk1.6
https://issues.apache.org/bugzilla/show_bug.cgi?id=53601 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID OS||All --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com --- You are wrong. 1). It is true that Tomcat trunk (aka Tomcat 8) builds only with jdk1.7. It is as intended. It is expected to implement the Servlet 3.1 specification. 2). Tomcat 7 builds with jdk1.6 and this status quo has not changed. Anyway your report noticeably lack of details. You should ask on the mailing list first, before playing around with Bugzilla. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53602] New: Support for HTTP status code 451
https://issues.apache.org/bugzilla/show_bug.cgi?id=53602 Priority: P2 Bug ID: 53602 Assignee: dev@tomcat.apache.org Summary: Support for HTTP status code 451 Severity: enhancement Classification: Unclassified OS: All Reporter: funk...@apache.org Hardware: All Status: NEW Version: trunk Component: Catalina Product: Tomcat 7 Index: java/org/apache/tomcat/util/http/res/LocalStrings.properties === --- java/org/apache/tomcat/util/http/res/LocalStrings.properties (revision 1365543) +++ java/org/apache/tomcat/util/http/res/LocalStrings.properties (working copy) @@ -65,6 +65,7 @@ sc.428=Precondition Required sc.429=Too Many Requests sc.431=Request Header Fields Too Large +sc.451=Unavailable For Legal Reasons sc.500=Internal Server Error sc.501=Not Implemented sc.502=Bad Gateway Submitting as enhancement instead of committing in case anyone has an objection. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53602] Support for HTTP status code 451
https://issues.apache.org/bugzilla/show_bug.cgi?id=53602 --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com --- Link to versions of the proposal to add this new status code to HTTP in IETF document tracking tool: https://datatracker.ietf.org/doc/draft-tbray-http-legally-restricted-status/history/ The current version of the document is 01. I do not mind adding the new status code, but the comment in the LocalStrings.properties file says that the codes come from IANA page, http://www.iana.org/assignments/http-status-codes/http-status-codes.xml Either a comment should be added on where the code comes from, or we can wait until a proper RFC is issued and IANA page is updated with the new code. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53602] Support for HTTP status code 451
https://issues.apache.org/bugzilla/show_bug.cgi?id=53602 --- Comment #2 from Rainer Jung rainer.j...@kippdata.de --- OK to add for me. The IANA link I added to the comments wasn't meant to police other status code additions but instead to be useful for future checks. So Tim, you might want to adjust that comment as you see fit. There are two places with HTTP status codes: tomcat/trunk/java/org/apache/catalina/valves/LocalStrings.properties tomcat/trunk/java/org/apache/tomcat/util/http/res/LocalStrings.properties You might want to add the new one to the other list as well. Regards, Rainer -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
tomcat 7.0.29 startup time
Hi Lords and Ladies! I'm currently wrangling with a doubled boot time on tomcat7.0.29 in comparison to 7.0.28 (12 webapps in my tc: 7.0.28 45s, 7.0.29 90s). I'm aware that 7.0.29 now does the scanning for ServletContainerInitializer even if version=2.5 is specified. But there shall no class scanning be performed if metadata-complete=true is set, right? The problem is that @HandlesTypes forces scanning. And regardless if you only scanning or the types registered via @HandlesTypes or searching for all - the startup time is almost the same. This is because the most expensive part is the file and zip handling... So even if the webapp is metadata-complete, it still performs all the class scanning. You can prove this by simply adding Apache MyFaces to a sample webapp. Any other sample which utilizes a ServletContainerInitializer and has @HandlesTypes will also do the job. In my case it's even more fatal: I have the FacesServlet configured via web.xml, so the whole MyFaces ServletContextInitializer is not used at all... Any ideas how we can ease the pain quickly? I know the Servlet-EG 'clarified' that only recently, but being an EG member myself I know exactly that this can be reverted if it only got 'recently clarified'. Nothing is set in stone until a final MR spec with an absolute binding wording got released. Mark, others, what about explaining the impact to the EG again and maybe they change their mind? For the long run you might be interested in commons-classscan we do over at commons atm. The idea is to have all sorts of ASF projects (tomcat, OpenWebBeans, OpenEJB, MyFaces, BVal, OpenJPA, ...) register their needs upfront and do the scanning only once. But it will take a bit until we have something to show off I fear as most of us are under heavy load in other ASF projects as well. LieGrue, strub - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 53469] possible bug in Response.normalize(CharChunk cc)
https://issues.apache.org/bugzilla/show_bug.cgi?id=53469 --- Comment #14 from Mark Thomas ma...@apache.org --- Folks, please re-read comment #11. The output of encodeURL() is not and never will be normalized. However, the Javadoc for encodeURL() allows/requires Tomcat to check if the session needs to be encoded in the provided URL. One of the checks Tomcat uses is whether or not the URL provided to encodeURL() is part of the web application. To do this correctly Tomcat has to construct a absolute, normalized URL to check whether the resulting URL is within the web application. This requires converting relative URLs to absolute and the only basis Tomcat has for doing this is the current request URL. Wicket is doing unusual things in pre-generating content for a different URL than the current one. This is causing problems for relative URLs. I have yet to find any evidence that any other framework does this. At the moment this looks like a Wicket specific issue. As previously stated, I will be changing Tomcat so that if the is the URL part of the webapp test fails (e.g. because normalization fails) the result will be that the session ID is not added to the URL. That may or may not be sufficient to fix this for Wicket. Some feedback on this would be appreciated. In terms of further fixing, I am leaning towards this being a Wicket specific issue (and hence a Wicket problem to fix) but I am open to contrary arguments. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-validate-eoln (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-validate-eoln has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk-validate-eoln : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/gump_work/build_tomcat-trunk_tomcat-trunk-validate-eoln.html Work Name: build_tomcat-trunk_tomcat-trunk-validate-eoln (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml validate-eoln [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/tomcat-trunk/output/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/classes [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/bin [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/conf [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/lib [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/logs [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/webapps compile-prepare: [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/java/org/apache/catalina/startup [copy] Copying 1 file to /srv/gump/public/workspace/tomcat-trunk/webapps/docs validate-eoln: [javac] Compiling 1 source file to /srv/gump/public/workspace/tomcat-trunk/output/classes [javac] javac: invalid target release: 1.7 [javac] Usage: javac options source files [javac] use -help for a list of possible options BUILD FAILED /srv/gump/public/workspace/tomcat-trunk/build.xml:523: Compile failed; see the compiler error output for details. Total time: 2 seconds - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/rss.xml - Atom: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-validate-eoln/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1326072012, vmgump.apache.org:vmgump:1326072012 Gump E-mail Identifier (unique within run) #7. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GUMP@vmgump]: Project tomcat-trunk-dbcp (in module tomcat-trunk) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-trunk-dbcp has an issue affecting its community integration. This issue affects 3 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-trunk : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-dbcp : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... - tomcat-trunk-test : Tomcat 8.x, a web server implementing Java Servlet 3.1, ... Full details are available at: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-dbcp/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Made directory [/srv/gump/public/workspace/tomcat-trunk/tomcat-deps] -INFO- Failed with reason build failed -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-dbcp/gump_work/build_tomcat-trunk_tomcat-trunk-dbcp.html Work Name: build_tomcat-trunk_tomcat-trunk-dbcp (Type: Build) Work ended in a state of : Failed Elapsed: 2 secs Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true -Dbuild.sysclasspath=only org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dcommons-pool.home=/srv/gump/public/workspace/commons-pool-1.x -Dcommons-dbcp.home=/srv/gump/public/workspace/commons-dbcp-1.x -Dtomcat-dbcp.jar=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps/tomcat-dbcp-26072012.jar -Dtomcat-dbcp.home=/srv/gump/public/workspace/tomcat-trunk/tomcat-deps build-tomcat-dbcp [Working Directory: /srv/gump/public/workspace/tomcat-trunk] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar - Buildfile: /srv/gump/public/workspace/tomcat-trunk/build.xml build-prepare: [delete] Deleting directory /srv/gump/public/workspace/tomcat-trunk/output/build/temp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/build/temp build-manifests: [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/output/manifests [copy] Copying 12 files to /srv/gump/public/workspace/tomcat-trunk/output/manifests build-tomcat-dbcp: [copy] Copying 70 files to /srv/gump/public/workspace/tomcat-trunk/tomcat-deps [patch] patching file src/java/org/apache/commons/dbcp/DelegatingCallableStatement.java [patch] Hunk #1 succeeded at 661 (offset -113 lines). [patch] patching file src/java/org/apache/commons/dbcp/cpdsadapter/DriverAdapterCPDS.java [patch] patching file src/java/org/apache/commons/dbcp/DelegatingResultSet.java [patch] Hunk #1 succeeded at 1079 (offset -195 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDataSource.java [patch] Hunk #1 succeeded at 437 (offset -52 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingConnection.java [patch] Hunk #1 succeeded at 678 (offset -126 lines). [patch] patching file src/java/org/apache/commons/dbcp/PoolingDriver.java [patch] Hunk #1 succeeded at 497 (offset -4 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingStatement.java [patch] Hunk #1 succeeded at 484 (offset -45 lines). [patch] patching file src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java [patch] Hunk #1 succeeded at 1204 (offset -173 lines). [patch] patching file src/java/org/apache/commons/dbcp/BasicDataSource.java [patch] Hunk #1 succeeded at 28 with fuzz 1. [patch] Hunk #2 succeeded at 1782 (offset -19 lines). [patch] patching file src/java/org/apache/commons/dbcp/datasources/InstanceKeyDataSource.java [patch] Hunk #1 succeeded at 887 (offset -1 lines). [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/tomcat-deps/src/java/org/apache/tomcat/dbcp [move] Moving 75 files to /srv/gump/public/workspace/tomcat-trunk/tomcat-deps/src/java/org/apache/tomcat/dbcp [mkdir] Created dir: /srv/gump/public/workspace/tomcat-trunk/tomcat-deps/classes [javac] Compiling 66 source files to
[Bug 53605] New: use tcnative-1.1.24 Tomcat shutdown still crash
https://issues.apache.org/bugzilla/show_bug.cgi?id=53605 Priority: P2 Bug ID: 53605 Assignee: dev@tomcat.apache.org Summary: use tcnative-1.1.24 Tomcat shutdown still crash Severity: normal Classification: Unclassified OS: Linux Reporter: juns...@taobao.com Hardware: PC Status: NEW Version: 1.1.24 Component: Library Product: Tomcat Native # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0039ec07aec6, pid=6348, tid=1280588096 # # JRE version: 6.0_26-b03 # Java VM: OpenJDK 64-Bit Server VM (20.0-b11-internal mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libc.so.6+0x7aec6] memset+0xc6 # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x7fa05d291000): JavaThread http-0.0.0.0-7001-Acceptor-0 daemon [_thread_in_native, id=6792, stack(0x4c443000,0x4c544000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x Registers: RAX=0x, RBX=0x7fa069448018, RCX=0x007a, RDX=0x RSP=0x4c542aa8, RBP=0x02f2, RSI=0x, RDI=0x0050 R8 =0x0050, R9 =0x0101010101010101, R10=0x7fa07b878964, R11=0x0039ec07aec6 R12=0x7fa06942edf8, R13=0x4c542bc0, R14=0x4c542c68, R15=0x7fa05d291000 RIP=0x0039ec07aec6, EFLAGS=0x00010206, CSGSFS=0x0033, ERR=0x0006 TRAPNO=0x000e Top of Stack: (sp=0x4c542aa8) 0x4c542aa8: 7fa0664aea25 7fa069448018 0x4c542ab8: 4c542bc0 7fa06942edf8 0x4c542ac8: 7fa0664aeeb7 7fa05d291000 0x4c542ad8: 4c542b80 4c542bf8 0x4c542ae8: 0007f454cd22 7fa00010 0x4c542af8: 0007492e3e40 4c542b20 0x4c542b08: 7fa07fd7273a 017fbbb20002 0x4c542b18: 4c542b60 0x4c542b28: 7fa07fd61e04 7fa05d291000 0x4c542b38: 7fa05d291000 0x4c542b48: 0007f454cd60 7fa05d291000 0x4c542b58: 4c542bd0 4c542bd0 0x4c542b68: 7fa07b8827c0 7fa07b875d18 0x4c542b78: 7fa0664acb90 0103 0x4c542b88: 7fa069447fd0 4c542c40 0x4c542b98: 7fa069447fd0 7fa06942ee70 0x4c542ba8: 7fa05d2911d0 0007efaa5d70 0x4c542bb8: 7fa0666d3672 0x4c542bc8: 7fa06942edf8 0007efaa5d78 0x4c542bd8: 4c542c40 0x4c542be8: 7fa07b878991 0007492e3e40 0x4c542bf8: 0007492e3e40 4c542c00 0x4c542c08: 4c542c68 0x4c542c18: 0007efaa75b0 0x4c542c28: 0007efaa5d78 0x4c542c38: 4c542c60 4c542cb0 0x4c542c48: 7fa07b86d9b3 0007efaa7548 0x4c542c58: 7fa07b875d17 7fa069447fd0 0x4c542c68: 000752dd11d8 4c542c70 0x4c542c78: 0007f454f770 4c542cd0 0x4c542c88: 0007f454fb60 0x4c542c98: 0007f454f7e8 4c542c60 Instructions: (pc=0x0039ec07aec6) 0x0039ec07aea6: ff 48 89 97 78 ff ff ff 48 89 57 80 48 89 57 88 0x0039ec07aeb6: 48 89 57 90 48 89 57 98 48 89 57 a0 48 89 57 a8 0x0039ec07aec6: 48 89 57 b0 48 89 57 b8 48 89 57 c0 48 89 57 c8 0x0039ec07aed6: 48 89 57 d0 48 89 57 d8 48 89 57 e0 48 89 57 e8 Register to memory mapping: RAX=0x is an unknown value RBX=0x7fa069448018 is an unknown value RCX=0x007a is an unknown value RDX=0x is an unknown value RSP=0x4c542aa8 is pointing into the stack for thread: 0x7fa05d291000 RBP=0x02f2 is an unknown value RSI=0x is an unknown value RDI=0x0050 is an unknown value R8 =0x0050 is an unknown value R9 =0x0101010101010101 is an unknown value R10=0x7fa07b878964 is an Interpreter codelet method entry point (kind = native) [0x7fa07b878740, 0x7fa07b878f20] 2016 bytes R11=0x0039ec07aec6: memset+0xc6 in /lib64/libc.so.6 at 0x0039ec00 R12=0x7fa06942edf8 is an unknown value R13=0x4c542bc0 is pointing into the stack for thread: 0x7fa05d291000 R14=0x4c542c68 is pointing into the stack for thread: 0x7fa05d291000 R15=0x7fa05d291000 is a thread Stack:
[Bug 53605] use tcnative-1.1.24 Tomcat shutdown still crash
https://issues.apache.org/bugzilla/show_bug.cgi?id=53605 --- Comment #1 from junshan juns...@taobao.com --- Created attachment 29116 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29116action=edit crash error log -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
