I am familiar with that FAQ.. when I first was playing with threads I too did not get threaded cores correctly. I have been running 2.4.21 for quite some time, and .16 before that. No problems with cores. core.12131 etc is dropped with full debug capabilities.
-D_REENTRANT must be defined for it to work if I remember correctly. threads are reentrant. Threads are so much easier in the end than fork due to the sharing of memory. ---- Original Message ----- From: "Jason Gauthier" <[EMAIL PROTECTED]> To: "Chris "Winston" Litchfield" <[EMAIL PROTECTED]>; <[email protected]> Sent: Monday, August 04, 2003 9:12 AM Subject: RE: Fork() > The distribution doesn't matter. It's the thread implementation. > > I didn't say you wouldn't get cores, just that it's not reliable. (read: > the core you get might not be from the thread that crashed) > > Read below from the Linuxthreads FAQ: > > > LinuxThreads Frequently Asked Questions > > > > G.2: Does it work with post-mortem debugging? > > > > Not very well. Generally, the core file does not correspond to the > > thread that crashed. The reason is that the kernel will not dump core > > for a process that shares its memory with other processes, such as the > > other threads of your program. So, the thread that crashes silently > > disappears without generating a core file. Then, all other threads of > > your program die on the same signal that killed the crashing thread. > > (This is required behavior according to the POSIX standard.) The last > > one that dies is no longer sharing its memory with anyone else, so the > > kernel generates a core file for that thread. Unfortunately, that's > > not the thread you are interested in. > > > > G.3: Any other ways to debug multithreaded programs, then? > > > > Assertions and printf() are your best friends. Try to debug sequential > > parts in a single-threaded program first. Then, put printf() > > statements all over the place to get execution traces. Also, check > > invariants often with the assert() macro. In truth, there is no other > > effective way (save for a full formal proof of your program) to track > > down concurrency bugs. Debuggers are not really effective for subtle > > concurrency problems, because they disrupt program execution too much. > > > > > > > -----Original Message----- > > From: Chris "Winston" Litchfield [mailto:[EMAIL PROTECTED] > > Sent: Sunday, August 03, 2003 6:56 PM > > To: Jason Gauthier; 'Dale Kingston'; [email protected] > > Subject: Re: Fork() > > > > Jason, > > > > I have no trouble with core dumps. 2.4 kernel set. You must > > use the later versions of GDB to get correct information out. > > I also use Mandrake instead of Redcrap. > > > > Chris > > ----- Original Message ----- > > From: "Jason Gauthier" <[EMAIL PROTECTED]> > > To: "'Chris "Winston" Litchfield'" <[EMAIL PROTECTED]>; > > "'Dale Kingston'" > > <[EMAIL PROTECTED]>; <[email protected]> > > Sent: Sunday, August 03, 2003 3:38 PM > > Subject: RE: Fork() > > > > > > > Only problem with using threads: > > > > > > If you are using linux, and a kernel that is not in the 2.5 > > or 2.6 series > > > you will not get reliable core dumps. > > > > > > If you don't care, then go for it. > > > > > > > > > > -----Original Message----- > > > > From: Chris "Winston" Litchfield [mailto:[EMAIL PROTECTED] > > > > Sent: Sunday, August 03, 2003 2:20 PM > > > > To: Dale Kingston; [email protected] > > > > Subject: Re: Fork() > > > > > > > > > > > > Just use threads. Its easier and works the same. > > > > > > > > Here is my init_descriptor using threads as an example. > > > > #include <pthread.h> > > > > > > > > pthread_t thread; > > > > > > > > pthread_create(&thread, NULL,(void *)init_descriptor,(void > > > > *)control); pthread_detach(thread); > > > > > > > > Init_descriptor instead of returns has "pthread_exit()" and > > > > you have a threaded app. > > > > > > > > create and exit. It uses the SAME memory you have now. > > > > > > > > > > > > > > > > compile with -lpthread > > > > > > > > ----- Original Message ----- > > > > From: "Dale Kingston" <[EMAIL PROTECTED]> > > > > To: <[email protected]> > > > > Sent: Saturday, August 02, 2003 9:44 PM > > > > Subject: Fork() > > > > > > > > > > > > > Does anyone know where I could read up on how to use > > fork()? Would > > > > > like > > > > the > > > > > mud to do something on the side, but it's going to take > > a second or > > > > > two to process it. > > > > > > > > > > Basically I've made a pfile cleaner to go through and > > clean up the > > > > > pfiles remove old ones what not. And I have it do a backup > > > > to when it > > > > > does this. But it causes the mud to halt for a second > > while it does > > > > > all this. So I've heard/seen a little bit on fork. But idk > > > > really how > > > > > to use it. This > > > > cleaner > > > > > is just one function so would I just like: > > > > > > > > > > if (fork()) > > > > > { > > > > > clean_pfiles(); > > > > > exit(0); > > > > > } > > > > > > > > > > Or how would I use fork to do that. I don't need > > anything from the > > > > > process information wise. I would just need it to run this one > > > > > function and the close the process. > > > > > > > > > > So if anyone knows somewhere, where I could read up on it. > > > > Or maybe an > > > > > explaininaion on how to do this would be very appreciated. > > > > > > > > > > > > > > > -- > > > > > ROM mailing list > > > > > [email protected] > > > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ROM mailing list > > > > [email protected] > > > > http://www.rom.org/cgi-bin/mailman/listinfo/rom > > > > > > > > > > > > > > > >
