Discussion:
Crash in sendto_kdc.c
mogasale.tech
2018-10-04 12:47:06 UTC
Permalink
Hi Team,



This is in continuation with below threads:

1.
http://mailman.mit.edu/pipermail/kfwdev/2018-February/date.html

2. http://mailman.mit.edu/pipermail/kfwdev/2018-May/date.html



We could get a crash dump for the scenarios explained above. From the dump,
below are the observations:

1. The crash is happening within “service_tcp_write” function of
“sendto_kdc.c”, while executing the if condition “if ((size_t)nwritten <
SG_LEN(sgp))”.
2. The issue doesn’t happen for all the requests, but is frequent in a
specific environment. We have not been able to determine a specific pattern
yet.
3. The observed values for relevant fields/variables from one of the
dumps are as below, all the dumps have the values in same pattern:

conn.state = WRITING

conn.addr.transport = TCP

conn.addr.family = 2

conn.addr.len = 16

conn.out.sgbuf[0] = {len = 4, buff = ‘\0’}

conn.out.sgbuf[1] = {len = 1882, buff = ‘some data’}

conn.out.sgp = {len=??? buf=??? }

conn.out.sg_count = -10339

conn.out.msg_len_buf = ""

nwritten = 3199132154



From the values above, it looks similar to the second possibility suggested
in http://mailman.mit.edu/pipermail/kfwdev/2018-February/000892.html.
However, we do not have any clue yet on what could be causing this.



Any help on this will be appreciated. Thanks


PS: We are using krb5 tag version 1.16-final (
https://github.com/krb5/krb5/blob/krb5-1.16-final/src/lib/krb5/os/sendto_kdc.c
)



Regards,

Rama
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/l
Greg Hudson
2018-10-04 20:01:13 UTC
Permalink
[Removing kfwdev from the CC line; we no longer have a separate Windows
development team, so just krbdev is fine.]
Post by mogasale.tech
conn.out.sgbuf[0] = {len = 4, buff = ‘\0’}
conn.out.sgbuf[1] = {len = 1882, buff = ‘some data’}
conn.out.sgp = {len=??? buf=??? }
conn.out.sg_count = -10339
conn.out.msg_len_buf = ""
nwritten = 3199132154
Thanks for the additional information. I think I finally know what is
going wrong here: SOCKET_WRITEV() is trying to return -1, but due to the
intricacies of the C type system, it is being treated as 2^32-1 on
64-bit Windows.

The fix I would like to try is to edit src/include/port-sockets.h and
change the first definition of SOCKET_WRITEV to:

#define SOCKET_WRITEV(FD, SG, LEN, TMP) \
(WSASend((FD), (SG), (LEN), &(TMP), 0, 0, 0) ? \
(ssize_t)-1 : (ssize_t)(TMP))

where the change is the addition of the (ssize_t) casts.

Without the casts, the type of the conditional expression is unsigned
32-bit, because -1 has type int and TMP has type DWORD, and unsigned
wins over signed for integer types of equal size. The quantity -1 in
that type has the value 2^32-1. When that value is cast to ssize_t
(signed 64-bit on 64-bit Windows), it retains the large positive value
instead of reverting back to -1 as it would on 32-bit Windows.
_______________________________________________
krbdev mailing list ***@mit.edu
htt
mogasale.tech
2018-10-05 09:25:11 UTC
Permalink
Thanks Greg. Will try that out and confirm.

Regards,
Rama
Post by Greg Hudson
[Removing kfwdev from the CC line; we no longer have a separate Windows
development team, so just krbdev is fine.]
Post by mogasale.tech
conn.out.sgbuf[0] = {len = 4, buff = ‘\0’}
conn.out.sgbuf[1] = {len = 1882, buff = ‘some data’}
conn.out.sgp = {len=??? buf=??? }
conn.out.sg_count = -10339
conn.out.msg_len_buf = ""
nwritten = 3199132154
Thanks for the additional information. I think I finally know what is
going wrong here: SOCKET_WRITEV() is trying to return -1, but due to the
intricacies of the C type system, it is being treated as 2^32-1 on
64-bit Windows.
The fix I would like to try is to edit src/include/port-sockets.h and
#define SOCKET_WRITEV(FD, SG, LEN, TMP) \
(WSASend((FD), (SG), (LEN), &(TMP), 0, 0, 0) ? \
(ssize_t)-1 : (ssize_t)(TMP))
where the change is the addition of the (ssize_t) casts.
Without the casts, the type of the conditional expression is unsigned
32-bit, because -1 has type int and TMP has type DWORD, and unsigned
wins over signed for integer types of equal size. The quantity -1 in
that type has the value 2^32-1. When that value is cast to ssize_t
(signed 64-bit on 64-bit Windows), it retains the large positive value
instead of reverting back to -1 as it would on 32-bit Windows.
_______________________________________________
krbdev mailing list ***@mit.edu

Loading...