I've hit a corner case of send/post getting confoozled when my VPN
connection died while sending.
Almost certainly relevant is my .mh_profile entry:
post: -msgid -server auth.smtp.vt.edu -port 587 -tls -sasl
[...]
Hrm.
I thought I check all of the read system calls for EOF ... and this
is a bit odd:
0x0000003a974d8580 in __read_nocancel () from /lib64/libc.so.6
(gdb) where
#0 0x0000003a974d8580 in __read_nocancel () from /lib64/libc.so.6
#1 0x0000003aa38ad741 in read (__nbytes=5, __buf=0x1620083,
__fd=<value optimized out>) at /usr/include/bits/unistd.h:45
#2 sock_read (b=0x1619e30, out=0x1620083 "\027\003\001", outl=5)
at bss_sock.c:142
#3 0x0000003aa38ab4d9 in BIO_read (b=0x1619e30, out=0x1620083, outl=5)
at bio_lib.c:212
#4 0x0000003aa8424ee5 in ssl3_read_n (s=0x1619a30, n=5, max=5,
extend=<value optimized out>) at s3_pkt.c:238
#5 0x0000003aa8425ebd in ssl3_get_record (s=0x1619a30) at s3_pkt.c:317
#6 ssl3_read_bytes (s=0x1619a30, type=23,
buf=0x7fffa2aec050 "-fsdevel(_at_)vger(_dot_)kernel(_dot_)org>...
Recipient ok\r\n\227:",
len=8192, peek=0) at s3_pkt.c:959
#7 0x0000003aa8423434 in ssl3_read_internal (s=0x1619a30, buf=0x7fffa2aec050,
len=8192, peek=0) at s3_lib.c:3265
#8 0x0000000000406786 in sm_fgetc ()
#9 0x0000000000406c1b in smhear ()
#10 0x0000000000407076 in smtalk ()
#11 0x0000000000407792 in sm_wtend ()
#12 0x0000000000403e89 in do_text ()
#13 0x000000000040413f in post ()
#14 0x0000000000405593 in main ()
sm_fgetc() isn't called directly from smhear(). But I think the
issue is that sm_rrecord() (calld by smhear()) can call sm_fgets(),
and if sm_fgets() gets an EOF, it returns RP_EOF ... and sm_rrecord()
just keeps spinning, because it will only stop on NOTOK (also -1).
Looks like it's easy enough to fix ... but makes me think I need to think
about how this error handling all works in there a bit more.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers