Re: [tcnative] jnilib.c: tcn_new_array* do not call EnsureLocalCapacity

Mark, On 5/15/24 15:49, Mark Thomas wrote: On 15/05/2024 13:53, Christopher Schultz wrote: All, We have a few functions in jnilib.c that create new local references e.g. tcn_new_stringn and most of them call EnsureLocalCapacity to make sure the thread doesn't run out of local references.

Re: [tcnative] Should we make DEBUG builds available for Windows?

with debug info and then produce two final libraries: one including those symbols and one with them stripped-out? In my dissassembly and investigation into that error message, the function doesn't look like it's from tcnative but actually one of the statically-linked objects bundled

Re: [tcnative] Should we make DEBUG builds available for Windows?

On 2024/05/15 13:12:44 Christopher Schultz wrote: > All, > > A recent thread was posted with a tcnative crash with not much in the > way of useful information in the error: > > https://lists.apache.org/thread/m1dbj3w1x1oqftqsbj7jbnvkm2073x1o > >

Re: [tcnative] jnilib.c: tcn_new_array* do not call EnsureLocalCapacity

On 15/05/2024 13:53, Christopher Schultz wrote: All, We have a few functions in jnilib.c that create new local references e.g. tcn_new_stringn and most of them call EnsureLocalCapacity to make sure the thread doesn't run out of local references. I'm fairly sure that calling New*Array will

Re: [tcnative] Home page lists 2.0.6 as latest release, points to 2.0.7 download

On 15/05/2024 13:34, Christopher Schultz wrote: All, Subject pretty much says it all. https://tomcat.apache.org/native-doc/ Latest release is stated to be 2.0.6 while the download link goes to 2.0.7. I know we announce tcnative releases on Tomcat's main news page, but since we have some

Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n

Rémy, On 5/15/24 09:12, Rémy Maucherat wrote: On Tue, May 14, 2024 at 11:15 PM Christopher Schultz wrote: All, I'd like to basically globally-search-and-replace ERR_error_string for ERR_error_string_n and use a #define constant for both the initialization of all char err[256]; and

[tcnative] Should we make DEBUG builds available for Windows?

All, A recent thread was posted with a tcnative crash with not much in the way of useful information in the error: https://lists.apache.org/thread/m1dbj3w1x1oqftqsbj7jbnvkm2073x1o The error details were: " # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x0001800ccd10, pid=1244

Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n

On Tue, May 14, 2024 at 11:15 PM Christopher Schultz wrote: > > All, > > I'd like to basically globally-search-and-replace ERR_error_string for > ERR_error_string_n and use a #define constant for both the > initialization of all > > char err[256]; > > and similar strings and use that same

[tcnative] jnilib.c: tcn_new_array* do not call EnsureLocalCapacity

All, We have a few functions in jnilib.c that create new local references e.g. tcn_new_stringn and most of them call EnsureLocalCapacity to make sure the thread doesn't run out of local references. I'm fairly sure that calling New*Array will fail if such references cannot be created, but

Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n

Michael, On 5/15/24 05:14, Michael Osipov wrote: On 2024/05/14 21:15:03 Christopher Schultz wrote: All, I'd like to basically globally-search-and-replace ERR_error_string for ERR_error_string_n and use a #define constant for both the initialization of all char err[256]; and similar

Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n

On 2024/05/14 21:15:03 Christopher Schultz wrote: > All, > > I'd like to basically globally-search-and-replace ERR_error_string for > ERR_error_string_n and use a #define constant for both the > initialization of all > > char err[256]; > > and similar strings and use that same constant

[tcnative] switch from using ERR_error_string to ERR_error_string_n

All, I'd like to basically globally-search-and-replace ERR_error_string for ERR_error_string_n and use a #define constant for both the initialization of all char err[256]; and similar strings and use that same constant for all calls to ERR_error_string_n.. Any objections? There

Re: Unit tests using tcnative/panama [Was: [Bug 68910] Improve LibreSSL version check in tcnative.m4]

for renegotiation or protocol mismatch. That looks very promising. Probably not relevant for this specific topic but maybe of general interest: For other reasons I tried to identify, which unit tests actually load and execute with tcnative and/or panama, and those are very few. Most tests

Unit tests using tcnative/panama [Was: [Bug 68910] Improve LibreSSL version check in tcnative.m4]

. That looks very promising. Probably not relevant for this specific topic but maybe of general interest: For other reasons I tried to identify, which unit tests actually load and execute with tcnative and/or panama, and those are very few. Most tests do not use these. Apart from the ones you mentioned

[Bug 67934] APR connectors will fail to load when tcnative-1 and tcnative-2 are installed in parallel

https://bz.apache.org/bugzilla/show_bug.cgi?id=67934 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 67934] New: APR connectors will fail to load when tcnative-1 and tcnative-2 are installed in parallel

https://bz.apache.org/bugzilla/show_bug.cgi?id=67934 Bug ID: 67934 Summary: APR connectors will fail to load when tcnative-1 and tcnative-2 are installed in parallel Product: Tomcat 9 Version: 9.0.x Hardware: All

[Bug 67934] APR connectors will fail to load when tcnative-1 and tcnative-2 are installed in parallel

https://bz.apache.org/bugzilla/show_bug.cgi?id=67934 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- You are

Re: tcnative crashes during shutdown (TC 10.x unit tests)

while still reproducing the issue? Mark Am 18.07.2022 um 12:09 schrieb Rainer Jung: Hi there, this is just an info, at this point probably not a showstopper. The topic is crashes in tcnative 1.2 and 2.0 for TC 10.0 during shutdown after TLS unit tests. Details: I ran the TC unit tests

Re: tcnative crashes during shutdown (TC 10.x unit tests)

Hi Jean-Frederic, Am 20.07.2022 um 08:47 schrieb jean-frederic clere: On 20/07/2022 00:16, Rainer Jung wrote: Roughly the same pattern I saw for TC 10.0 now also seen for TC 10.1. May be something wrong in apr? Which apr version are you using? - the same APR library for tcnative 1.2.35

Re: tcnative crashes during shutdown (TC 10.x unit tests)

not a showstopper. The topic is crashes in tcnative 1.2 and 2.0 for TC 10.0 during shutdown after TLS unit tests. Details: I ran the TC unit tests for latest 9.x, 10.x and 10.1.x with tcnative 1.2.35 OpenSSL 1.1.1q, 1.2.35 OpenSSL 3.0.2 and 2.0.1 OpenSSL 3.0.2. I ran the test for a variety of OpenJDK builds

Re: tcnative crashes during shutdown (TC 10.x unit tests)

Roughly the same pattern I saw for TC 10.0 now also seen for TC 10.1. Am 18.07.2022 um 12:09 schrieb Rainer Jung: Hi there, this is just an info, at this point probably not a showstopper. The topic is crashes in tcnative 1.2 and 2.0 for TC 10.0 during shutdown after TLS unit tests. Details

tcnative crashes during shutdown (TC 10.x unit tests)

Hi there, this is just an info, at this point probably not a showstopper. The topic is crashes in tcnative 1.2 and 2.0 for TC 10.0 during shutdown after TLS unit tests. Details: I ran the TC unit tests for latest 9.x, 10.x and 10.1.x with tcnative 1.2.35 OpenSSL 1.1.1q, 1.2.35 OpenSSL

Re: Compiler warnings when compiling tcnative with -Wall -pedantic -ansi

ds %ld, itrealvalue %ld, 176 * starttime %llu (!) */ Note the (!) in the comment. I'm not sure if that's meant to indicate a known issue with the variable and format or not. There are similar (!) notations on line 174 for each of those items. Rainer laid that code into os/unix/system.c all a

Compiler warnings when compiling tcnative with -Wall -pedantic -ansi

All, When compiling with these extra flags, we get a raft of errors which are mostly: 1. Use of "long long" which is an "extension" 2. Use of // style comments 3. Use of mixed declarations and code When setting -std=C99 all of these go away. This flag works with both gcc and clang, but I

[Bug 63405] Tomcat 7.0.91.0 EXCEPTION_ACCESS_VIOLATION - Problematic frame tcnative-1.dll+0x802e

https://bz.apache.org/bugzilla/show_bug.cgi?id=63405 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|---

Re: First impressions from OpenSSL 3.0.0 and TC 10.0.0-M7 plus tcnative 1.2.24

Chris, Am 03.08.20 um 18:26 schrieb Christopher Schultz: > Rainer, > > On 8/3/20 07:03, Rainer Jung wrote: > > Hi Chris, hi all, > > > I ran build and tests for TC 10.0.0-M7 plus tcnative 1.2.24 and > > compared them between OpenSSL 3.0.0alpha5 and 1.1.1g plus pat

Re: First impressions from OpenSSL 3.0.0 and TC 10.0.0-M7 plus tcnative 1.2.24

before doing a release. Not saying this is good to do, it's just what is most easily available to me. In the case here it was 1.1.1g plus everything that was committed to the 1.1.1 branch until 2020-07-11. There's noting specifically needed for tcnative. I think the concept of ENGINE was mostly

Re: First impressions from OpenSSL 3.0.0 and TC 10.0.0-M7 plus tcnative 1.2.24

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rainer, On 8/3/20 07:03, Rainer Jung wrote: > Hi Chris, hi all, > > I ran build and tests for TC 10.0.0-M7 plus tcnative 1.2.24 and > compared them between OpenSSL 3.0.0alpha5 and 1.1.1g plus patches. > APR was always 1.7.0. Th

First impressions from OpenSSL 3.0.0 and TC 10.0.0-M7 plus tcnative 1.2.24

Hi Chris, hi all, I ran build and tests for TC 10.0.0-M7 plus tcnative 1.2.24 and compared them between OpenSSL 3.0.0alpha5 and 1.1.1g plus patches. APR was always 1.7.0. - build warnings for tcnative using OpenSSL 3.0.0alpha5: src/ssl.c:422:5: warning: 'ENGINE_by_id' is deprecated

[Bug 63405] Tomcat 7.0.91.0 EXCEPTION_ACCESS_VIOLATION - Problematic frame tcnative-1.dll+0x802e

https://bz.apache.org/bugzilla/show_bug.cgi?id=63405 Michael Osipov changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Michael

Re: Unbundling Commons Daemon and tcnative

On 09/10/2019 21:34, Michael Osipov wrote: > Am 2019-10-09 um 19:14 schrieb Mark Thomas: >> On 09/10/2019 17:36, Michael Osipov wrote: >>> I have been wondering recently why are we bundling >>> commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a >>> new release at all? >> >>

Re: Unbundling Commons Daemon and tcnative

Am 2019-10-09 um 19:14 schrieb Mark Thomas: On 09/10/2019 17:36, Michael Osipov wrote: I have been wondering recently why are we bundling commons-daemon-native.tar.gz and tomcat-native.tar.gz every time with a new release at all? Because users find it convenient to have the latest versions

Re: Unbundling Commons Daemon and tcnative

fferent operating systems. > > We can say/document that Tomcat release T requires libtcnative x.y.z and > Commons Daemon a.b.c to run, get your own from dist.apache.org if you do > it manually. I think that is less convenient for users. > More confusing is that apache-tomcat-8.5.48-dev-wind

Unbundling Commons Daemon and tcnative

fusing is that apache-tomcat-8.5.48-dev-windows-*.zip bundles tcnative-1.dll (which is huge in size, OpenSSL statically linked?) *and* the source tarball, same for Commons Daemon. Why? Opinions? Michael - To unsubscribe, e-mai

Re: tcnative and JDK13/14

-64.so.2    NEEDED   libgcc_s.so.1 When building tcnative against OpenSSL 1.0.x, the JVM has already loaded OpenSSL 1.0 system libs via the above dependency and will not load our tcnative dependency. This lead to a subtle failure in my case: /usr/local/jdk13/bin/java: symbol lookup

Re: tcnative and JDK13/14

   libcrypto.so.1.0.0   NEEDED   libc.so.6   NEEDED   ld-linux-x86-64.so.2   NEEDED   libgcc_s.so.1 When building tcnative against OpenSSL 1.0.x, the JVM has already loaded OpenSSL 1.0 system libs via the above dependency and will not load our tcnative

tcnative and JDK13/14

libdl.so.2 NEEDED libssl.so.1.0.0 NEEDED libcrypto.so.1.0.0 NEEDED libc.so.6 NEEDED ld-linux-x86-64.so.2 NEEDED libgcc_s.so.1 When building tcnative against OpenSSL 1.0.x, the JVM has already loaded OpenSSL 1.0

[Bug 63405] Tomcat 7.0.91.0 EXCEPTION_ACCESS_VIOLATION - Problematic frame tcnative-1.dll+0x802e

https://bz.apache.org/bugzilla/show_bug.cgi?id=63405 kd changed: What|Removed |Added Status|NEEDINFO|NEW -- You are receiving this mail because: You

[Bug 63405] Tomcat 7.0.91.0 EXCEPTION_ACCESS_VIOLATION - Problematic frame tcnative-1.dll+0x802e

https://bz.apache.org/bugzilla/show_bug.cgi?id=63405 --- Comment #2 from kd --- server.xml REST API were invoked at the time of crash. We also use Websocket for client server communication.

[Bug 63405] Tomcat 7.0.91.0 EXCEPTION_ACCESS_VIOLATION - Problematic frame tcnative-1.dll+0x802e

https://bz.apache.org/bugzilla/show_bug.cgi?id=63405 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO OS|

[Bug 63514] Tomcat 8.0.23 crash (tcnative-1.dll+0x7e75)

https://bz.apache.org/bugzilla/show_bug.cgi?id=63514 --- Comment #5 from yoooman --- So I can only update the version first to solve this error(（tcnative-1.dll + 0x7e75) But there is no way to confirm whether it will happen after the updated version. -- You are receiving this mail because: You

[Bug 63514] Tomcat 8.0.23 crash (tcnative-1.dll+0x7e75)

https://bz.apache.org/bugzilla/show_bug.cgi?id=63514 --- Comment #4 from Mark Thomas --- Those are all questions for the users mailing list. -- You are receiving this mail because: You are the assignee for the bug. - To

[Bug 63514] Tomcat 8.0.23 crash (tcnative-1.dll+0x7e75)

https://bz.apache.org/bugzilla/show_bug.cgi?id=63514 --- Comment #3 from yoooman --- If we don't update, what parts will not be supported, what kind of errors will be caused? -- You are receiving this mail because: You are the assignee for the bug.

[Bug 63514] Tomcat 8.0.23 crash (tcnative-1.dll+0x7e75)

https://bz.apache.org/bugzilla/show_bug.cgi?id=63514 --- Comment #2 from yoooman --- What is the oldest version supported now? -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail:

[Bug 63514] Tomcat 8.0.23 crash (tcnative-1.dll+0x7e75)

https://bz.apache.org/bugzilla/show_bug.cgi?id=63514 Mark Thomas changed: What|Removed |Added OS||All Resolution|---

[Bug 63514] New: Tomcat 8.0.23 crash (tcnative-1.dll+0x7e75)

https://bz.apache.org/bugzilla/show_bug.cgi?id=63514 Bug ID: 63514 Summary: Tomcat 8.0.23 crash (tcnative-1.dll+0x7e75) Product: Tomcat Native Version: 1.1.33 Hardware: PC Status: NEW Severity: critical

[Bug 63405] New: Tomcat 7.0.91.0 EXCEPTION_ACCESS_VIOLATION - Problematic frame tcnative-1.dll+0x802e

https://bz.apache.org/bugzilla/show_bug.cgi?id=63405 Bug ID: 63405 Summary: Tomcat 7.0.91.0 EXCEPTION_ACCESS_VIOLATION - Problematic frame tcnative-1.dll+0x802e Product: Tomcat Native Version: unspecified Hardware: PC

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=58194 --- Comment #8 from Christopher Schultz --- (In reply to Mark Thomas from comment #7) > Tomcat 1.1.x reached [EOL ...] Just for clarification, this should have been "_tcnative 1.1.x_ reached EOL..." -- You are receiving this mail because:

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=58194 Mark Thomas changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEEDINFO

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=58194 Eduardo Guadalupe Quintanilla changed: What|Removed |Added CC||eduardo...@gmail.com

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=58194 ithan changed: What|Removed |Added CC|equintani...@bnext.mx, |ithanr...@gmail.com

Re: Help with windows tcnative crash

On 22/08/18 14:47, Mark Thomas wrote: > On 22/08/18 13:41, Christopher Schultz wrote: >> All, >> >> Can someone take a quick look at my analysis of the tcnative crash >> described here: >> https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 >> >> With

Re: Help with windows tcnative crash

Am 22.08.2018 um 15:47 schrieb Mark Thomas: On 22/08/18 13:41, Christopher Schultz wrote: All, Can someone take a quick look at my analysis of the tcnative crash described here: https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 Without a debugger in Windows, I don't think I'll be able

Re: Help with windows tcnative crash

On 22/08/18 13:41, Christopher Schultz wrote: > All, > > Can someone take a quick look at my analysis of the tcnative crash > described here: > https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 > > Without a debugger in Windows, I don't think I'll be able to find the

Help with windows tcnative crash

All, Can someone take a quick look at my analysis of the tcnative crash described here: https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 Without a debugger in Windows, I don't think I'll be able to find the line of code where the problem is. There is an offset into the DLL where the error

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 --- Comment #9 from Mark Thomas --- Buildbot fixed. We might want to revisit the change to test.apr.loc since changing to a directory that exists by default enables the APR test run which then fails when APR is not present. -- You are

Re: [Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

On 29/06/18 19:25, bugzi...@apache.org wrote: > https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 > > --- Comment #8 from Mark Thomas --- > The problem (on buildbot) is that bin/native did not exist so the test for APR > failed (it looks for the directory) so the APR tests did not run. > >

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 --- Comment #8 from Mark Thomas --- The problem (on buildbot) is that bin/native did not exist so the test for APR failed (it looks for the directory) so the APR tests did not run. With this change the dir does exist, so the APR tests run and

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 --- Comment #7 from Remy Maucherat --- But it broke CI, since it would be using the old location. The test.apr.loc property can be changed in the env there (but I don't know how to do it). -- You are receiving this mail because: You are the

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 Remy Maucherat changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 --- Comment #5 from Remy Maucherat --- (In reply to Mark Thomas from comment #4) > bin/native > - new location I didn't make it up, it's really used by the testsuite, line 82 of build.xml: But it's not a real "user", so I'll change it. --

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 --- Comment #4 from Mark Thomas --- I am strongly +1 for being consistent with the native library location across the test suite, the installer and the other distributions. I'm neutral on whether it should be bin or bin/native bin - is what

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 --- Comment #3 from Remy Maucherat --- For 56676, I added bin/native as a default location for tcnative. So ... : - The default location can be changed to just "bin" and the testsuite should be adjusted to reflect that - The ins

[Bug 62284] tcnative-1.dll not loaded in windows nanoserver

https://bz.apache.org/bugzilla/show_bug.cgi?id=62284 Remy Maucherat changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 62284] tcnative-1.dll not loaded in windows nanoserver

https://bz.apache.org/bugzilla/show_bug.cgi?id=62284 Luca Giuliani - Gewiss changed: What|Removed |Added OS||All

[Bug 62284] New: tcnative-1.dll not loaded in windows nanoserver

https://bz.apache.org/bugzilla/show_bug.cgi?id=62284 Bug ID: 62284 Summary: tcnative-1.dll not loaded in windows nanoserver Product: Tomcat 8 Version: 8.5.12 Hardware: PC Status: NEW Severity: normal Priority

Re: tcnative experts: please have a look at BZ 53940

Am 19.03.2018 um 15:13 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/19/18 9:54 AM, Mark Thomas wrote: On 19/03/18 13:52, Christopher Schultz wrote: All, I'm guessing this is mostly directed towards Rainer: can someone look at

Re: tcnative experts: please have a look at BZ 53940

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 3/19/18 9:54 AM, Mark Thomas wrote: > On 19/03/18 13:52, Christopher Schultz wrote: >> All, >> >> I'm guessing this is mostly directed towards Rainer: can someone >> look at https://bz.apache.org/bugzilla/show_bug.cgi?id=53940? >> It's

Re: tcnative experts: please have a look at BZ 53940

On Mon, Mar 19, 2018 at 2:54 PM, Mark Thomas wrote: > On 19/03/18 13:52, Christopher Schultz wrote: > > All, > > > > I'm guessing this is mostly directed towards Rainer: can someone look > > at https://bz.apache.org/bugzilla/show_bug.cgi?id=53940? It's got a > > proposed patch

Re: tcnative experts: please have a look at BZ 53940

On 19/03/18 13:52, Christopher Schultz wrote: > All, > > I'm guessing this is mostly directed towards Rainer: can someone look > at https://bz.apache.org/bugzilla/show_bug.cgi?id=53940? It's got a > proposed patch and IMO makes sense to implement. > > I'm not familiar enough with OpenSSL and the

tcnative experts: please have a look at BZ 53940

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm guessing this is mostly directed towards Rainer: can someone look at https://bz.apache.org/bugzilla/show_bug.cgi?id=53940? It's got a proposed patch and IMO makes sense to implement. I'm not familiar enough with OpenSSL and the way that

[Bug 55087] tomcat crashes in tcnative-1.dll with OCSP when OCSP server is not reachable

https://bz.apache.org/bugzilla/show_bug.cgi?id=55087 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 --- Comment #2 from Konstantin Kolinko --- > a. Improve documentation. Add a note and a recipe to My recipe is to configure "java.library.path" explicitly. For running Tomcat in Eclipse IDE the steps are the

[Bug 61632] Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

|All --- Comment #1 from Konstantin Kolinko <knst.koli...@gmail.com> --- > b. Implement some way to search for tcnative-1.dll in ${catalina.home}/bin ? For this solution I thought that maybe 1. Allow to configure an explicit path to the dll in AprLifecycleListener 2. Use System.load(filenam

[Bug 61632] New: Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base)

https://bz.apache.org/bugzilla/show_bug.cgi?id=61632 Bug ID: 61632 Summary: Improve search for tcnative-1.dll on Windows when current directory is not bin/ (e.g. in Eclipse IDE, separate catalina_base) Product: Tomcat 8

Re: OK to require tcnative 1.2.14 for TC 8.5 once it is available?

On Sun, Sep 3, 2017 at 10:26 AM, Mark Thomas <ma...@apache.org> wrote: > On 02/09/17 21:40, Rainer Jung wrote: > > Backporting some fixes and enhancements from TC trunk to 8.5.x would > > need to either require tcnative 1.2.14 or make the code more complex by > > catchi

Re: OK to require tcnative 1.2.14 for TC 8.5 once it is available?

Am 03.09.2017 um 10:26 schrieb Mark Thomas: On 02/09/17 21:40, Rainer Jung wrote: Backporting some fixes and enhancements from TC trunk to 8.5.x would need to either require tcnative 1.2.14 or make the code more complex by catching UnsatisfiedLinkError etc. and converting into error messages

Re: OK to require tcnative 1.2.14 for TC 8.5 once it is available?

On 02/09/17 21:40, Rainer Jung wrote: > Backporting some fixes and enhancements from TC trunk to 8.5.x would > need to either require tcnative 1.2.14 or make the code more complex by > catching UnsatisfiedLinkError etc. and converting into error messages. > > I don't remember ve

OK to require tcnative 1.2.14 for TC 8.5 once it is available?

Backporting some fixes and enhancements from TC trunk to 8.5.x would need to either require tcnative 1.2.14 or make the code more complex by catching UnsatisfiedLinkError etc. and converting into error messages. I don't remember very well, how we handled this in the past. Are we willing

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=58194 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment

[Bug 49038] Crash in tcnative

https://bz.apache.org/bugzilla/show_bug.cgi?id=49038 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED

[Bug 57140] tcnative-1.dll 1.1.31 indicated in fatal error

https://bz.apache.org/bugzilla/show_bug.cgi?id=57140 Mark Thomas changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug 56313] Tomcat 8 crashes in tcnative-1.dll+0x7923

https://bz.apache.org/bugzilla/show_bug.cgi?id=56313 Mark Thomas changed: What|Removed |Added CC|

[Bug 56313] Tomcat 8 crashes in tcnative-1.dll+0x7923

https://bz.apache.org/bugzilla/show_bug.cgi?id=56313 Mark Thomas changed: What|Removed |Added CC||martin.ha...@ysoft.com

[Bug 56415] EXCEPTION_ACCESS_VIOLATION (0xc0000005) in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=56415 Mark Thomas changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug 56313] Tomcat 8 crashes in tcnative-1.dll+0x7923

https://bz.apache.org/bugzilla/show_bug.cgi?id=56313 Mark Thomas changed: What|Removed |Added CC||kmash...@yahoo.com

[Bug 61422] Feature requests for tc-native based on forked netty-tcnative

https://bz.apache.org/bugzilla/show_bug.cgi?id=61422 Mark Thomas changed: What|Removed |Added OS||All

[Bug 61422] New: Feature requests for tc-native based on forked netty-tcnative

https://bz.apache.org/bugzilla/show_bug.cgi?id=61422 Bug ID: 61422 Summary: Feature requests for tc-native based on forked netty-tcnative Product: Tomcat Native Version: unspecified Hardware: PC Status: NEW

[Bug 61149] Tomcat 8.5.14 - Crash in [tcnative-1.dll+0x1091a0]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61149 Remy Maucherat changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug 61149] New: Tomcat 8.5.14 - Crash in [tcnative-1.dll+0x1091a0]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61149 Bug ID: 61149 Summary: Tomcat 8.5.14 - Crash in [tcnative-1.dll+0x1091a0] Product: Tomcat Native Version: 1.2.10 Hardware: PC Status: NEW Severity: critical

[Bug 61149] Tomcat 8.5.14 - Crash in [tcnative-1.dll+0x1091a0]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61149 Thomas changed: What|Removed |Added CC|

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=58194 hseh...@gmail.com changed: What|Removed |Added OS||All --- Comment #5 from

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x000180007e75, pid=2928, tid=4560 # # JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [tcnative-1

[Bug 53605] use tcnative-1.1.24 Tomcat shutdown still crash

https://bz.apache.org/bugzilla/show_bug.cgi?id=53605 Mark Thomas changed: What|Removed |Added Resolution|--- |WORKSFORME

[Bug 53605] use tcnative-1.1.24 Tomcat shutdown still crash

https://bz.apache.org/bugzilla/show_bug.cgi?id=53605 Mark Thomas changed: What|Removed |Added Attachment #29116|application/octet-stream|text/plain

[Bug 55113] FIPS-compatible OpenSSL fails fingerprint test in TCNative with FIPS mode on

https://bz.apache.org/bugzilla/show_bug.cgi?id=55113 --- Comment #5 from Christopher Schultz --- Excellent. Thanks a bunch, Mark. Building with VS and OpenSSL is really no fun at all. -- You are receiving this mail because: You are the assignee for the bug.

[Bug 55113] FIPS-compatible OpenSSL fails fingerprint test in TCNative with FIPS mode on

https://bz.apache.org/bugzilla/show_bug.cgi?id=55113 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED

[Bug 58194] Tomcat crash EXCEPTION_ACCESS_VIOLATION in tcnative-1.dll

https://bz.apache.org/bugzilla/show_bug.cgi?id=58194 Eduardo Guadalupe Quintanilla changed: What|Removed |Added CC|

[Bug 55087] tomcat crashes in tcnative-1.dll with OCSP when OCSP server is not reachable

https://bz.apache.org/bugzilla/show_bug.cgi?id=55087 Ravi changed: What|Removed |Added Attachment #33912|0 |1 is obsolete|

[Bug 55087] tomcat crashes in tcnative-1.dll with OCSP when OCSP server is not reachable

https://bz.apache.org/bugzilla/show_bug.cgi?id=55087 Ravi changed: What|Removed |Added CC||ravi...@gmail.com ---

  1   2   3   4   5   6   >