Tcl

Tracker: Bugs

4 Seg fault from usleep - ID: 1160057

Last Update: Comment added ( hobbs )

Details:

Am trying to determine what may be going on in tcl that
causes this code to crash. Using a main instead of tcl
to run the code it appears to work fine.

The computer is running MandrakeLinux 10.1:

kernel: 2.6.8.1-12mdksmp
gcc: 3.4.3-1mdk
glibc: 2.3.3-21mdk
tcl: 8.4.5-6mdk

Code:

#include <stdint.h>
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <tcl.h>

class Message
{
public:
Message();
~Message ();
};

Message::Message() {}
Message::~Message () {}

static void *RecallTaskEntry(void *_this)
{
Message m;
usleep(2000000);
return 0;
}

extern "C" int createThread() {
pthread_t Recallthread;
pthread_create(&Recallthread,NULL,RecallTaskEntry, 0);
usleep (50000);
pthread_cancel (Recallthread);
pthread_join (Recallthread, NULL);
return 0;
}

int TclCreateThread (ClientData clientData, Tcl_Interp
*interp,
int argc,CONST84 char *argv[])
{
createThread ();
return TCL_OK;
}

extern "C" int Thread_Init(Tcl_Interp *interp) {

Tcl_CreateCommand(interp,"createThread",TclCreateThread,
0, 0);
return TCL_OK;
}

extern "C" int Thread_SafeInit(Tcl_Interp *interp) {
return (Thread_Init(interp));
}

Code is C++ compiled as a shared library and run in tcl
via:

load libThread.so
createThread

The observed beviour is a segfault which results from
doing a pthread_cancel when the thread is in the
usleep. The debugger output looks a little confused
like possible stack corruption. However as explained
it works ok standalone outside of tcl.

Things that seem to make it work are:

- Removing the Message object from the thread.
- Removing Messages destructor.
- As a test using sleep and pause instead of usleep
appear to work.

Any ideas on what is causing this bug?

Submitted:

Simon White ( s_a_white ) - 2005-03-09 17:49

Priority:

Status:

Open

Resolution:

None

Assigned:

Andreas Kupries

Category:

49. Threading

Group:

obsolete: 8.4.9

Visibility:

Public

Comments ( 6 )

Date: 2005-10-05 08:05 Sender: hobbs Logged In: YES user_id=72656 Reducing prio as I'm still suspicious that Tcl is at fault here.
Date: 2005-10-05 07:48 Sender: s_a_white Logged In: YES user_id=59929 Am not sure... The problem only started when moving to a newer Linux distribution and as yet have not been able to try a new one. The compiler has gone from gcc 3.3 to 3.4 (last distribution used the old compiler). I believe 3.4 is still consider "stable" and gcc 4 what to start aiming for but may contain bugs, The major thing I note about this Linux distribution was the change to ntpl which was causing various other problems for us (mainly how thread cancelation was now being handled during cout.... now exception rather than cancelation point, sem_wait can now also return -1... not according to the docs). To be honest I wasn't sure which list to ask TCL, glibc, C++ or gcc (note I've tried contacting glibc as they do the nptl, but no response). As noted the problem only appears when run in TCL, rather than a standalone main. As stated running tcl under valgrind with the same test made the problem disappear. Am I running with threads enabled, probably not. This is a prebuilt version by the distribution. All TCL does is make calls to external functions that start/stop threads and occasionally grab mutexs, but those threads do not access any tcl functions or keep track of any tcl memory (objects).
Date: 2005-10-05 05:31 Sender: hobbs Logged In: YES user_id=72656 Is this a possible compiler bug? Are you making sure to compile Tcl with --enable-threads? I'm not sure how this really relates to Tcl, vs. being a C++ issue.
Date: 2005-09-21 09:59 Sender: s_a_white Logged In: YES user_id=59929 This appears to be somehow exception related. Compiling with -fno-exceptions prevents the segfault.
Date: 2005-03-13 10:20 Sender: nobody Logged In: NO Additional things I've tried that had no effect, and still resulted in a segfault. -Updating glibc to offical release 2.3.4 -Updating kernel to to official release 2.6.11.2 Haven't yet updated the compiler as no newer official releases.
Date: 2005-03-10 22:42 Sender: nobody Logged In: NO Have updated tcl to 8.4.9 and rebuilt the code. Ran it up using tclsh (didn't update tk) and still the seg fault appears. Interestingly I tried valgrind on tclsh and get various complaints about mallocs/free's, but the seg fault disappeared, hmmm.

Attached File

Changes ( 7 )

Field	Old Value	Date	By
priority	8	2005-10-05 08:05	hobbs
status_id	Pending	2005-10-05 07:48	s_a_white
close_date	2005-10-05 05:31	2005-10-05 07:48	s_a_white
status_id	Open	2005-10-05 05:31	hobbs
close_date	-	2005-10-05 05:31	hobbs
priority	5	2005-03-14 00:51	dkf
artifact_group_id	None	2005-03-13 07:01	dkf

Tcl

Tracker: Bugs

Comments ( 6 )

Attached File

No Files Currently Attached

Changes ( 7 )

About SourceForge

Find Software

Develop Software

Community

Help