Menu

#34 Common C++ thread stack size troubles

Common_Libraries
pending
nobody
Library (32)
5
2012-11-18
2007-03-17
No

Setting the thread's stack size with Thread::setStack() (or with the constructor) doesn't work. The thread's stack size remains `ulimit -s` (= 8192) as described in http://nptl.bullopensource.org/Tests/NPTL-limits.html. This limits the maximum number of threads approximately to ~ 380 on my i686-pc-linux-gnu machine, due to the 3G/1G user/kernel space split. I didn't get any useful error messages from Common C++, the example program just stops silently... If someone needs more threads to run, the stack size must be decreased.

The stack sizing code in thread.cpp, which is surrounded by #ifdef PTHREAD_STACK_MIN [...] #endif is never executed, becouse the definition from limits.h is not included here, and the configure script doesn't define HAVE_PTHREAD_ATTR_SETSTACK (it doesn't check for pthread_attr_setstack()) in which case the PTHREAD_STACK_MIN would be defined as 32768 in ost_pthread.m4.

After figuring this out, I manually set the stack size with pthread_attr_setstackize() and I ran into another problem, which is similar to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145941. With using -pthread the final executable will call the old __pthread_create_2_0() function, which version (pthread_create@GLIBC_2.0) doesn't set any stack size inside, it just ignores this part of the attribute, and sets the default stack size again. I replaced -pthread with -lpthread, and this solved the issue, the new __pthread_create_2_1() (pthread_create@@GLIBC_2.1) was called, which really sets the stack size. However I think -pthread should work as well, and I don't really understand why changing to -lpthread solved the problem. Maybe it's just a distribution specific issue, I just tried on Ubuntu 6.06 and FC3...

After these modification I was able create and run thousands of threads, but the glibc double free, corruption errors haven't disappeared, as I described in http://lists.gnu.org/archive/html/ccrtp-devel/2007-03/msg00002.html.

Discussion

  • David Sugar

    David Sugar - 2012-11-18

    What I got out of this is that we should include limits.h in thread.cpp, and this was done for ucommon 6. As to how this applies to older/broken threading library implimentations I am not sure. I don't think it applies to current distros, though.

     
  • David Sugar

    David Sugar - 2012-11-18
    • status: open --> pending
     

Log in to post a comment.