Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <524DEFCF.2010307@christopherschultz.net>
Date: Thu, 03 Oct 2013 18:29:35 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: Recent tcnative null-dereference with 8.0.0-RC3 and 7.0.45
 [tcnative-1.dll+0x7e23]
References: <5246199A.70000@christopherschultz.net>
 <5246AEB6.5050509@kippdata.de> <5246B613.6010504@apache.org>
 <52492924.1040205@apache.org> <52497DE2.4010007@apache.org>
 <524999BB.1010007@christopherschultz.net> <5249B7FE.2060200@apache.org>
 <5249C801.3030908@christopherschultz.net> <524A5550.8040701@apache.org>
 <524A72BA.60709@kippdata.de> <524AD8E6.6010607@christopherschultz.net>
 <524ADE95.4030304@apache.org> <524AE07E.5020604@christopherschultz.net>
 <CAOGo0VZRqLDW5j9-DQmLfCma7coGR_wALp5TezzLzJtXCauV3A@mail.gmail.com>
 <524BACA4.8080008@apache.org>
 <CAOGo0VY+j2+9uf+HqiEBvqbC9nZktgN1v5-UoWDrPvH3WjwZ5A@mail.gmail.com>
 <524D683B.8080609@christopherschultz.net> <524D6EB3.4020209@apache.org>
 <524D894B.9030808@christopherschultz.net> <524D9051.6040903@apache.org>
 <524D9C85.3000602@christopherschultz.net> <524DCAE5.6030704@apache.org>
In-Reply-To: <524DCAE5.6030704@apache.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="0WmmxtIJWTFNwp1pD72Hi57c6fVagCLex"

--0WmmxtIJWTFNwp1pD72Hi57c6fVagCLex
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Mark,

On 10/3/13 3:52 PM, Mark Thomas wrote:
> On 03/10/2013 17:34, Christopher Schultz wrote:
>> On 10/3/13 11:42 AM, Mark Thomas wrote:
>=20
>>> On the other hand, a JVM crash is a very strong motivation to fix
>>> an issue.
>=20
>> For *you*, or for the user?
>=20
> For me. I haven't looked at the historical bugs. The APR code has
> changed so much for WebSocket I'd be inclined to close all the
> historical issues as WORKSFORME (assuming they didn't come with a
> reproducible test case) and focus on the current code.

I kind of agree.... many of those reports are ooooold.

>> Certainly it is for the user, but given the number of unfixed crash
>> reports in Bugzilla, it doesn't seem like tcnative-crash=3Dquick-fix
>> from the team. I've been trying to investigate them whenever
>> possible but it's hard for me to get more information and, frankly,
>> I don't know anything about APR socket management itself so my time
>> is only of limited use.
>=20
> The AprEndpoint can be hard to get your head around starting from
> scratch. It has taken me a long time to feel comfortable making
> changes to that code. More comments in the AprEndpoint code should
> help. I've been trying to add them as I make changes.
>=20
>>> - documenting some of the constraints around using SSL would
>>> have saved me some time when getting SSL and WebSocket working
>=20
>> Can you be more specific without just writing the documentation=20
>> yourself? I'm hoping to help, but I'm not sure what SSL constraints
>> you are alluding to.
>=20
> If you get a partial read/write you have to repeat the call with
> exactly the same parameters (i.e. the same objects) as you made the
> first call.

Interesting. So partial-write means that you should just idempotently
re-try?

>>> -730053
>=20
>> This one isn't valid, as far as I can tell (the error string is=20
>> "Unrecognized resolver error"). 70053 is "Error string not
>> specified yet" so I'm not sure what that one is.
>=20
> 720000 is the offset for OS native error codes.
> 10053 is client abort on Windows.

Aah, Windows. No wonder I couldn't find the error code on Linux ;)

>>> I can look them up to figure what they mean but it would save
>>> some time if the error report included a text version.
>=20
>> tcnative doesn't have an error log, so where could those strings
>> go? Or were you thinking of having a bridge from Java code into
>> apr_strerr?
>=20
> I was thinking maybe an APR function that gave a textual error message
> for a given error code. Currently, the APR Java code reports just the
> error number. It would be nice to include a meaningful text message.

Okay, that's something I can do: a JNI wrapper around apr_strerror
should be trivial.

>> What about a program like perror that understands APR error codes?
>> I've written a simple one that could be helpful, but you probably
>> did that yourself already.
>=20
> Nope. I use Google :)

LOL. Really.

I've got a quick and dirty C program that compiles cleanly on Mac,
Linux. I suppose it would compile on Windows, but I don't have a win32
compiler.

>> Anywhere more information can be added, I'm happy to help.
>=20
>>>>> - Refactoring the connectors so all socket access goes
>>>>> through the SocketWrapper so there is a much smaller set of
>>>>> code to validate.
>>>>
>>>> I'm guessing you are tackling this task slowly over time.
>>>
>>> I am moving slowly in this direction. My ultimate aim is to have
>>> the connector type specific code only in the Endpoint and the=20
>>> SocketWrapper. No idea if that is possible. It is a longer term
>>> goal for Tomcat 9+ at this point.
>>>
>>> At the very least whenever I add functionality to the connectors
>>> (e.g. non-blocking IO) I do enough refactoring that I only have
>>> to add the new stuff once.
>=20
>> Sounds good. Having unified code with only certain aspects
>> separated into BIO, NIO, and APR will certainly help folks like me
>> understand the "true" conceptual relationship between all of these
>> components and make it easier to actually help work on that part of
>> the code.
>=20
> Exactly. Simpler maintenance is one of my goals when reducing the
> duplication in the connector code. It is also something that can often
> be done in small and/or simple steps. There is always scope for
> someone to start contributing in that area (with the caveat that they
> need to be careful not to bite off more than they can chew - it is
> also easy to get into a right mess).

:)

-chris


--0WmmxtIJWTFNwp1pD72Hi57c6fVagCLex
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSTe/PAAoJEBzwKT+lPKRY6DMP/0baVnsYEGHaTQWb76s6qM6Q
q+qVlaiNqa/L1R3OTyQm8obqujty6u6LubiFvFWFV81UyfY7XAz+U8XcdT9dmozI
p12Yee12ICP1p33xYQmWwa7cC2y8aWFTXxJMi4p7rVLAY2lr9HTK96QSImKJVJvk
C0no3B6uXGTVfmh1fQHLoRZwF61/RNRZBfoT14xlgdcHx0yHeLUmLm0pK8RB03/5
jJhXRRt6StP5qFGwxZQM1ycSYebe6RGt0YALnrWdaFPZQzaOOewoHHmdHZGsoeBM
QtWteGhSLP+J0hT8RH3oMjdZgJO/UIqbM7C+a1R0UAe+jzeQlje2THr0CmIhlLmB
byvtbYrd6lEDBSm8i0fzVn8nEn1Bkms5NMGZgFgrJgz8jIHh0ioT1CyJh6hcI85a
XUAd3OkuKGPHP3UJY1nvgbZrQHywI70d5OLhm9HawQKSpEIEKwL6612lLOAMxZpQ
TudIS6iXoC+RiZOl+HXULnseb+Mrc8O5psiPTKoyVIMA/kQldLPVuPyJozsMHH+u
ggDdSM7+Ofuo7bzuJeK61YygqOho1MnBldTWXSfn4RO2mbpDURzb/GWVheJa+jER
oQkx9GosANstJgbk8LlgGzblLcH/+qxm6F9NOHKueX94i9rMuQCnC+nIr4eAVORE
fDUo0DYsiBPCxzsHBTIR
=XAm/
-----END PGP SIGNATURE-----

--0WmmxtIJWTFNwp1pD72Hi57c6fVagCLex--