Thanks.
I notice your first write() is on fd 3 while the 2nd is on stdout (while
for me the first 2 are on fd 3, which in my case is the LDAPS socket).
For the issue to be reproduced, we need the client to be paused after
having send the TLS "client hello".
The first time the breakpoint is hit, you should be seeing something
like:
```
#0 __GI___libc_write (fd=3, buf=0x555555ace4ab, nbytes=75) at
../sysdeps/unix/sysv/linux/write.c:27
#1 0x00007ffff797b408 in sb_debug_write (sbiod=0x555555ab4810,
buf=0x555555ace4ab, len=75) at ../../../../libraries/liblber/sockbuf.c:854
#2 0x00007ffff6bd5a0a in _gnutls_writev_emu (fd=fd@entry=0x55555578f240,
giovec=giovec@entry=0x7fffffff9b90, giovec_cnt=giovec_cnt@entry=3,
vec=0, session=<optimized out>, session=<optimized out>) at buffers.c:447
#3 0x00007ffff6bd608c in _gnutls_writev (total=126, giovec_cnt=3,
giovec=0x7fffffff9b90, session=0x55555578d3d0) at buffers.c:504
#4 _gnutls_io_write_flush (session=session@entry=0x55555578d3d0) at
buffers.c:698
#5 0x00007ffff6bd7200 in _gnutls_handshake_io_write_flush
(session=session@entry=0x55555578d3d0) at buffers.c:820
#6 0x00007ffff6bd9348 in _gnutls_send_handshake
(session=session@entry=0x55555578d3d0, bufel=bufel@entry=0x555555acd620,
type=type@entry=GNUTLS_HANDSHAKE_FINISHED) at handshake.c:1335
#7 0x00007ffff6bda4ed in _gnutls_send_finished (again=<optimized out>,
session=0x55555578d3d0) at handshake.c:763
#8 send_handshake_final (session=session@entry=0x55555578d3d0,
init=init@entry=1) at handshake.c:3098
#9 0x00007ffff6bdcd29 in handshake_client (session=0x55555578d3d0) at
handshake.c:2946
#10 gnutls_handshake (session=0x55555578d3d0) at handshake.c:2626
#11 0x00007ffff7bbb183 in tlsg_session_accept (session=0x555555abb070) at
tls_g.c:361
#12 0x00007ffff7bb8751 in ldap_int_tls_connect (ld=ld@entry=0x5555557890d0,
conn=<optimized out>) at tls2.c:362
#13 0x00007ffff7bb9466 in ldap_int_tls_start (ld=ld@entry=0x5555557890d0,
conn=conn@entry=0x555555789500, srv=srv@entry=0x555555789440)
at tls2.c:860
#14 0x00007ffff7b912b6 in ldap_int_open_connection (ld=ld@entry=0x5555557890d0,
conn=conn@entry=0x555555789500, srv=0x555555789440,
async=async@entry=0) at open.c:448
#15 0x00007ffff7ba634d in ldap_new_connection (ld=ld@entry=0x5555557890d0,
srvlist=srvlist@entry=0x555555789198, use_ldsb=use_ldsb@entry=1,
connect=connect@entry=1, bind=bind@entry=0x0, m_req=m_req@entry=0, m_res=0)
at request.c:487
#16 0x00007ffff7b9074a in ldap_open_defconn (ld=ld@entry=0x5555557890d0) at
open.c:41
#17 0x00007ffff7ba7908 in ldap_send_initial_request
(ld=ld@entry=0x5555557890d0, msgtype=msgtype@entry=96, dn=dn@entry=0x0,
ber=0x5555557894a0,
msgid=1) at request.c:130
#18 0x00007ffff7b9ab8f in ldap_sasl_bind (ld=0x5555557890d0, dn=0x0,
mechanism=<optimized out>, cred=0x5555557692e0 <passwd>, sctrls=0x0,
cctrls=0x0, msgidp=0x7fffffffa2dc) at sasl.c:164
#19 0x000055555555d33b in ?? ()
#20 0x000055555555844f in ?? ()
#21 0x00007ffff7388bf7 in __libc_start_main (main=0x5555555581b0, argc=4,
argv=0x7fffffffe638, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe628) at
../csu/libc-start.c:310
#22 0x000055555555966a in ?? ()
```
And we need to make sure the server or client doesn't reject that
connection outright.
It would worth running "tshark -i any -f 'port 636'" in the mean time to
verify the "client hello" is sent and that the server is willing to
carry on the connection.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
