From: Uwe Klein on
Hi,
inside an expect script that connects to an external datasrc
via a TCP socket, then spawns -open $sock, then exp_background for
multiple regexp patterns incl. expecting eof, I reopen and respawn
the TCP connection to my external source when it "goes away" i.e.
the eof script agument is run.
inside that script I then rebuild the exp_background arguments
with a new spawn_id and overwrite the currently running exp_background.

Somehwere in this convoluted script I get:

Program received signal SIGSEGV, Segmentation fault.
0xb7d13268 in exp_close () from /usr/lib/libexpect5.43.0.so
(gdb) bt
#0 0xb7d13268 in exp_close () from /usr/lib/libexpect5.43.0.so
#1 0xb7d298e2 in exp_close_all () from /usr/lib/libexpect5.43.0.so
#2 0xb7d22cca in exp_exit_handlers () from /usr/lib/libexpect5.43.0.so
#3 0xb7f473d1 in Tcl_Finalize () from /usr/lib/libtcl8.4.so
#4 0xb7f4743e in Tcl_Exit () from /usr/lib/libtcl8.4.so
#5 0xb7d1236b in ?? () from /usr/lib/libexpect5.43.0.so
#6 0x00000000 in ?? ()

Seems to happen in takedown of the currently active spawn_id.

It is independent of using 8.4, 8.5native or from activestate
and the full range of recent expect versions.

Just asking around for now:
Anybody seen something similar?

uwe
From: Alexandre Ferrieux on
On Jun 13, 3:15 pm, Uwe Klein <uwe_klein_habertw...(a)t-online.de>
wrote:
> Hi,
> inside an expect script that connects to an external datasrc
> via a TCP socket, then spawns -open $sock, then exp_background for
> multiple regexp patterns incl. expecting eof, I reopen and respawn
> the TCP connection to my external source when it "goes away" i.e.
> the eof script agument is run.
> inside that script I then rebuild the exp_background arguments
> with a new spawn_id and overwrite the currently running exp_background.
>
> Somehwere in this convoluted script I get:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7d13268 in exp_close () from /usr/lib/libexpect5.43.0.so
> (gdb) bt
> #0  0xb7d13268 in exp_close () from /usr/lib/libexpect5.43.0.so
> #1  0xb7d298e2 in exp_close_all () from /usr/lib/libexpect5.43.0.so
> #2  0xb7d22cca in exp_exit_handlers () from /usr/lib/libexpect5.43.0.so
> #3  0xb7f473d1 in Tcl_Finalize () from /usr/lib/libtcl8.4.so
> #4  0xb7f4743e in Tcl_Exit () from /usr/lib/libtcl8.4.so
> #5  0xb7d1236b in ?? () from /usr/lib/libexpect5.43.0.so
> #6  0x00000000 in ?? ()
>
> Seems to happen in takedown of the currently active spawn_id.
>
> It is independent of using 8.4, 8.5native or from activestate
> and the full range of recent expect versions.
>
> Just asking around for now:
> Anybody seen something similar?

Sorry I am totally outside the Expect subspace, but I did take part in
the "exit reform" of the 8.6 branch (see bug 2001201), ending up with
Tcl_Exit no longer calling Tcl_Finalize. So, when you say "recent
expect versions", is it recent enough to include that reform
(committed to 8.6 HEAD on 2009-06-17) ?

-Alex

PS: Note that your crash may of course be orthogonal, and still occur
after the reform; it's just that the stack trace you posted includes a
now impossible sequence: Tcl_Exit..Tcl_Finalize.
From: Uwe Klein on

Alexandre Ferrieux wrote:
Hi Alex, thanks for your response.

> Sorry I am totally outside the Expect subspace, but I did take part in
> the "exit reform" of the 8.6 branch (see bug 2001201), ending up with
> Tcl_Exit no longer calling Tcl_Finalize. So, when you say "recent
> expect versions", is it recent enough to include that reform
> (committed to 8.6 HEAD on 2009-06-17) ?

probably not. But I go via [package require Expect].


A: expect 5.43.0 for tcl 8.4.15 both as included in SuSE linux 10.3
B: expect 5.44.1.15 as included in the active state distrib for tcl 8.5.8
( all for ia32 on a Toshiba Portege M100 )

And thanks:
your interpretation put my attention on the fact that
the crash seems to happen in the takedown after an uncaught error
rather than directly in my exchange of spawn_ids ( still shouldn't happen.)

explains why I could not reduce the problem into a simple script.

>
> -Alex
>
> PS: Note that your crash may of course be orthogonal, and still occur
> after the reform; it's just that the stack trace you posted includes a
> now impossible sequence: Tcl_Exit..Tcl_Finalize.

Don't have an 8.6 at hand.

uwe