We're having a problem with threaded programs that use the STL.  Given the
following program:

--START--
#include <string>
#include <pthread.h>

typedef map<int, int> mymap_t;

#ifdef GLOBLOCK
pthread_mutex_t glob_mut;
#endif

void *run(void *) {

        while (1) {
                string f("");
#ifdef GLOBLOCK
                pthread_mutex_lock(&glob_mut);
#endif
                f += "adsasd";
                f += "adsasd";
                f += "adsasd";
#ifdef GLOBLOCK
                pthread_mutex_unlock(&glob_mut);
#endif
        }

}

int main () {

        #define FOO 50
        pthread_t thread[FOO];

        for(int x =0;x<FOO;x++) {
                pthread_create(&thread[x], NULL, run, NULL);
        }

        for(int x =0;x<FOO;x++) {
                pthread_join(thread[x], NULL);
        }       

        exit(0);
}
---END---

When compiled like so:

c++ -g -pthread -o stl_core.cc stl_core.cc

The program will core after about 10 seconds, every time.  When compiled
with -DGLOBLOCK, it runs without fail.  I have tried this using gcc 2.95.1,
2.95.2, egcs-20001002 and 20001106 without success.  I have also tried using
the linuxthreads port, and with Matt Dillon's lowmem patch (can't remember
the URL offhand) and with Daniel Eischen's libc_r patches against -stable.

Under RedHat Linux 7.0 (kernel 2.2.16) using gcc 2.96 (development version),
the program works fine.

It would appear that there is an issue with some low-level allocator in the
STL as shipped in 4.x.  Because everything in the STL is build around said
allocator, this fails for almost anything that uses STL (the original test
program I used allocated a map rather than a string).

I'd appreciate any ideas this brings forth in people.

Thanks.

-- 
j.

James FitzGibbon                                           [EMAIL PROTECTED]
Targetnet.com Inc.                              Voice/Fax +1 416 306-0466/0452


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to