Hi Ian! I'm a new 'expect' maintainer and I'm trying to get into your bug with a newer expect 5.44.1.14.
Ian Beckwith <i...@nessie.mcc.ac.uk> wrote: > Expect seems to have intermittent semi-random problems during > processing of large amounts of binary data. > > The attached scripts, testspew (expect) and spew (perl) originally had a > telnet connection between them (I'm SIGSEGV hunting in telnetd-ssl) > but if I take out the telnet connection the problem still appears. > > Put them both in the same directory, make them executable, then do: > > ./testspew|cat -A I've executed testspew and found an interesting result. It behaves differently in different locales. In ru_RU.CP1251 it definitely fails on number 128 (0x80), in C seems to work fine until about 1000000 (then I've stopped it). So, probably the issue is not in expect (or the bug is just fixed upstream apparently), but in the way Tcl works with channels. Tcl assigns some encoding to a channel and recodes every character to and from that encoding (to when you send info out, from when you receive it in). By default Tcl assigns system encoding to every created channel which is very convenient for reading/writing text, but not so convenient when working with binary data. So, I've added four lines right after [spawn] command: fconfigure $user_spawn_id -translation binary fconfigure $spawn_id -translation binary fconfigure $error_spawn_id -translation binary fconfigure $tty_spawn_id -translation binary After that testspew became working in ru_RU.CP1251 locale as well. Could you test this findings and hopefully confirm that the new expect version works fine and just needs extra care when working with binary data? Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
