nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Send/post is intolerant of network errors


From: Ken Hornstein
Subject: Re: [Nmh-workers] Send/post is intolerant of network errors
Date: Sat, 08 Jan 2011 22:32:33 -0500

>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 "address@hidden>... 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]