-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
All,
On 5/21/13 3:00 PM, Christopher Schultz wrote:
> All,
>
> On 5/21/13 1:25 PM, James Snider wrote:
>> [error occurred during error reporting (printing native stack),
>> id 0xc0000005]
>
>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j
>> org.apache.tomcat.jni.Socket.sendbb(JII)I+0
>
> The only line of code in Socket.sendbb that could possibly(*) be
> causing a SEGV is this one:
>
> ss = (*s->net->send)(s->opaque, s->jsbbuff + offset + sent, &wr);
>
> Both s->opaque and s->jsbuff have been null-checked via
> assertions(*) so only s->net or s->net->send could be null.
s->net is set to NULL when "destroy" or "close" are called, so it's
plausible that this is the problem. What I didn't see what there was a
null-check against the "jint sock" parameter independent of the
cast-to-tcn_socket_t.
tcn_socket_t.net is this structure:
typedef struct {
int type;
apr_status_t (*cleanup)(void *);
apr_status_t (APR_THREAD_FUNC *close) (apr_socket_t *);
apr_status_t (APR_THREAD_FUNC *shutdown) (apr_socket_t *,
apr_shutdown_how_e);
apr_status_t (APR_THREAD_FUNC *opt_get)(apr_socket_t *,
apr_int32_t, apr_int32_t *);
apr_status_t (APR_THREAD_FUNC *opt_set)(apr_socket_t *,
apr_int32_t, apr_int32_t);
apr_status_t (APR_THREAD_FUNC *timeout_get)(apr_socket_t *,
apr_interval_time_t *);
apr_status_t (APR_THREAD_FUNC *timeout_set)(apr_socket_t *,
apr_interval_time_t);
apr_status_t (APR_THREAD_FUNC *send) (apr_socket_t *, const char
*, apr_size_t *);
apr_status_t (APR_THREAD_FUNC *sendv)(apr_socket_t *, const struct
iovec *, apr_int32_t, apr_size_t *);
apr_status_t (APR_THREAD_FUNC *recv) (apr_socket_t *, char *,
apr_size_t *);
} tcn_nlayer_t;
On a 64-bit architecture, the "send" pointer will be at offset=8*8 =
64d or 0x40, which is exactly the offset reported for the SEGV in the
core dump:
siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000040
It looks like we need another NULL check for s->net before attempting
to send data to the socket.
> * The assertions themselves could be causing a problem, as they
> look like this:
>
> TCN_ASSERT(s->opaque != NULL); TCN_ASSERT(s->jsbbuff != NULL);
>
> So, if "s" is null, it could cause the seg fault. Since "s" is
> passed-in from Java code (it's a jint), it probably should be
> checked for NULL before dereferencing it.
The win32 build of tcnative is unlikely to be in "DEBUG" mode, so the
TCN_ASSERTs end up being no-ops.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJRm8d7AAoJEBzwKT+lPKRYD5AP/1JsceHfMdJIksp6KTthSQ+b
RuOot3r4It0EPAERaUHleIpw5h/0xZ3RJ8q6ZU1wy43g0JzUse7jm2dDR9vkfldg
rxDStLeyLnnvPFdo117akgQRA4ix4hKaIzP21Qvud9CA1B9h99DODZhfVqxJcU/C
pDFzOumlvt8yRBCfJuC6g9yqEmjoSf2m0FObRxbQQBY4TYceWFu3uoP5f5VCWYOd
hePerYh5wtkBaIgDJBVgUd1TJx36+sirlNBcVCxTL3SPy5BwumuomWT+jJnAxW+C
qr2IrLPnRlBVtnwJYU83RZlM3sqsZKpk/fz0PS7pe8SEKBmIZegijQRmyuN/o6VE
6AE6+uLqjIiRpK7ZkF3W0qZ9uOl1I2Flpg74yRQ0BxZZJhNqnmTCRtMUqlgHWRZ8
vpm6Tkb5gyPpQ0kggoVaoFy4vEEqhVPE2kiw00ESjmWxjjNBEW4qf33QGHs5LFKz
+OXQQmMG+WVxFzS4UpbkvTELKitKzDOWm2MYwNSiYZtdvZOyR/nUZ+B8IklcNIw/
3pVXM7++VK6IQN1rHz6UUhFVx2xsJ89qn0FENbmvdmJHgXsguPz8YhPlCnJZl4GH
wzsfsyJCNOT0W10eUIUyVNgVMNesvZQLVKYdi7fQlbFAOtkvUkUmOJusFF0850s9
cqSvvuZ3ei6Qj6XyfXw9
=LAjP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
