From: Uwe Klein on 13 Jun 2010 09:15 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 13 Jun 2010 17:01 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 14 Jun 2010 04:45 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
|
Pages: 1 Prev: TileQt - the current status Next: how to stop using anti-aliased under X11 in tk8.5 |