Threadsafe issue with malloc / free, corrupted thread index

David Burrow David.Burrow@fds.com
Tue Jan 2 23:13:00 GMT 2007



All,

Have been working on an application for some weeks and need to check a
basic assumption.  Is cygwin's malloc( ) and free( ) thread-safe? I have
found ancient messages that indicate that it was not at one time, and a
more recent message that seemed to say that specific use of _malloc_r( ) or
_free_r( ) were no longer required.

In a formerly multi-threaded design, and now in a multi-process design, I
am plagued with a common error...

"*** fatal error - called with threadlist_ix -1

I've searched this mail list for clues, and have found some, but have not
understood the error enough to correct my issue.  Most recently I've
stepped through the code using GDB and can recreate this issue this time.
The following (simplified) pseudo code fragment describes my issue:


char     *errmsg = NULL;    // a pointer that stores the error string
int      rc = 0;
sqlite3   *sl3_db;           // an opened sqlite database..
char     *sql;              // Various SQL strings, in this case "CREATE
TABLE" statements

for (int n = 0;n < 8; n++)
{
   rc = sqlite3_exec(sl3_db,sql,NULL,NULL,NULL);
   if (rc)
   {
      if (errmsg) free((char*)errmsg);
      errmsg = malloc(strlen(sqlite3_errmsg(sl3_db) + 1));
      strcpy((char*)db->errmsg,sqlite3_errmsg(sl3_db));
   }
}

The goal is to store the most recent error string from a call to a sqlite
API. Each call to sqlite3_exec( ) returns a  error, as expected, as this
code is called in a redundant initialization section. I could clean this
up, ask first and create only as required, but I don't think it matters
much to my issue.

On the first iteration, the free is not done, as there is no former stored
error string. On iteration 5 of the 8, the thread pool is corrupted.  I've
checked that all my SQL strings are sane (null terminated).  I've checked
that the address being free( )'d is the one previously returned by malloc(
).  The loop is about this tight, so there is not much additional code (and
none that manipulates memory) between the malloc and free that is shown.
I've simplified the environment to be running just the parent process and
this child process code, where the parent is stopped at a breakpoint in
it's GDB -- so no other known threads/processes are running.

I'm not "newbie" new, but lack tons of experience.  I just need to hear
someone say either this is weird, or that my assumptions are wrong.  As a
nice-to-have, a link to any documentation on the thread-safeness of POSIX
functions in general would be appreciated....

In case it matters, I'm using the Eclipse's CDT.

TIA


(See attached file: cygcheck.out)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck.out
Type: application/octet-stream
Size: 25867 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20070102/7308edd2/attachment.obj>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


More information about the Cygwin mailing list