[Tcl-bugs] [ tcl-Bugs-2981154 ] async.test segfault

[SourceForge.net <no...@so...>]

Bugs item #2981154, was opened at 2010-04-02 17:11
Message generated for change (Comment added) made by ferrieux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2981154&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 49. Threading
Group: obsolete: 8.5.8
Status: Open
Resolution: None
Priority: 9
Private: No
Submitted By: Don Porter (dgp)
Assigned to: Andreas Kupries (andreas_kupries)
Summary: async.test segfault

Initial Comment:

Using the 8.5.8 sources (so I rule out more recent commits)
and with a --enable-threads --enable-symbols build, I
sometimes see a segfault at the end of async.test.

I managed to catch it in gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x40646b90 (LWP 825)]
0x0814bcfb in Tcl_MutexLock (mutexPtr=0x10)
    at /home/dgp/cvs/tcl8.5/unix/../unix/tclUnixThrd.c:519
519         if (*mutexPtr == NULL) {


(gdb) bt
#0  0x0814bcfb in Tcl_MutexLock (mutexPtr=0x10)
    at /home/dgp/cvs/tcl8.5/unix/../unix/tclUnixThrd.c:519
#1  0x08067c88 in Tcl_AsyncMark (async=0x8e0b274)
    at /home/dgp/cvs/tcl8.5/unix/../generic/tclAsync.c:167
#2  0x08054baf in AsyncThreadProc (clientData=0x8e16c18)
    at /home/dgp/cvs/tcl8.5/unix/../generic/tclTest.c:936
#3  0x080c1fbd in NewThreadProc (clientData=0xbbe12f0)
    at /home/dgp/cvs/tcl8.5/unix/../generic/tclEvent.c:1487
#4  0x0088773b in start_thread () from /lib/libpthread.so.0
#5  0x007dccfe in clone () from /lib/libc.so.6


Don't know whether this is another symptom of 
Tcl Bug 2869384.

I believe that when the segfault happens, it is
always after test async-4.3 has failed
(Tcl Bug 1774689).  However, async-4.3
can also fail without a segfault following.



----------------------------------------------------------------------

>Comment By: Alexandre Ferrieux (ferrieux)
Date: 2011-08-19 00:59

Message:
Come to think of it, as mistachkin noted, the whole test setup is geared
towards (a), ie there's absolutely no effort to be teardown-proof. So
playing with too small stretches of BC is completely out of the intended
range.
Hence, I believe the proper fix is to increase the size of the loopless BC
stretch in that test.

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2011-08-19 00:51

Message:
Probability of segfault gets close to 1 with 15 instead of 150 in the
modified loop.
Theory: the asyncmark may happen:
  (a) during the loopless stretch of BC 
  (b) during the main interp's teardown
  (c) not at all, since the process has exited
Clearly only the gray area (b) segfaults. I guess during teardown things
are not as airtight as during normal operation.

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2011-08-19 00:14

Message:
I also get non-systematic segfault, but there're news: the non-segfaulting
is correlated to Tcl_AsyncMark *not* being called. It's an iff. So there's
a race condition that hides the segfault by not letting the thread go far
enough.

----------------------------------------------------------------------

Comment By: Alexandre Ferrieux (ferrieux)
Date: 2011-08-18 23:44

Message:
Quoting mistachkin in 1774689:

   To see this test fail reliably, simply change the line in proc hang3
   from: [string repeat {;incr i;} 1500000] to: [string repeat {;incr i;}
   150]

doing this I get it reliably on trunk tip.

----------------------------------------------------------------------

Comment By: Don Porter (dgp)
Date: 2011-04-14 17:39

Message:
FWIW, I just saw this one again on trunk tip.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2981154&group_id=10894