HI, Thanks for all the info! > kse_release() in this context isn't kernel code, its from libpthread. > The kernel equivalent of a segfault would generate a panic. > > Just in case: you're attempting to allocate more than 5000 threads: > Each one from main tries to recursively create 5000 more, and so on. > Also note that because you are not calling pthread_join() (and aren't > creating "detatched" threads) you're leaking memory as each thread > exits. that is a good point.. in this specific case, at the end of my thread, it is a while (1) loop, so normally the thread i am creating will never exit, it is supposed to be a malicious prog to STRESS the system.. I will try the things you are suggesting, keep you posted. thanks for all the pointers! yan
> Now, if it's actually dying on the 5000ish thread mark: > > Also, each thread will allocate a stack + some extra overhead. The > default stack size is 64K. That means you're allocating 312MB of stack > space, and 5000 x some constant on top of that. That might exceed your > process's data segment size (though I'm not sure that limit is imposed > entirely by FreeBSDs malloc: I suspect it isn't) > > It's certainly a lot of memory for a 32-bit process. You could try > increasing your data segment size with ulimit(1), or decreasing the > stack size per thread with > pthread_attr_init/pthread_attr_setstacksize(). > > Also: gdb for corefiles may have been broken in 5.3, showing the > backtrace of the wrong stack. (I fixed one problem post release, but > I'm not sure if it was introduced before or after. Can you either run > the program from gdb (so you debug a live process rather than a > corefile), or try updating gdb? > _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
