Distribution: Vanilla kernel Hardware Environment: x86_64 Software Environment: ? Problem Description: If an application is multi-threaded, the linux kernel will append the pid number to the core file, even if echo 0 > /proc/sys/kernel/core_uses_pid. From looking at fs/exec.c, this looks intentional. Steps to reproduce: Set core_uses_pid to 0 and core_pattern to core. Compile the following program (stolen from Bug 5826). kill -SEGV it. The core file will have the pid number appended to it. For those who like to copy/paste: cat <<EOF > threader.c #include <pthread.h> static void* thread_sleep(void* x) { while (1) sleep(30); } int main(int c, char** v) { const static int tcount = 5; pthread_t thr[tcount]; int i; for (i=0; i<tcount; ++i) pthread_create(&thr[i], NULL, thread_sleep, NULL); while (1) sleep(30); return 0; } EOF gcc threader.c -o threader -l pthread echo 0 > /proc/sys/kernel/core_uses_pid echo core > /proc/sys/kernel/core_pattern ulimit -c 5000 ./threader & sleep 1 rm -f core* kill -SEGV %1 ls core*
Created attachment 7726 [details] Suggested fix The easiest fix would be to remove the phrase 'atomic_read(¤t->mm->mm_users) != 1'; then the kernel will behave as it is documented. If this is undesireable, then the attached patch could also work. This adds '%q' as a core-pattern option, which simulates pid_in_pattern. The patch updates the documentation as well.
bugme-daemon@bugzilla.kernel.org wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=6312 > > Summary: core_uses_pid=0 not always honored > Kernel Version: 2.6.15.2 > Status: NEW > Severity: normal > Owner: other_other@kernel-bugs.osdl.org > Submitter: dmlee@crossroads.com > > > Distribution: > Vanilla kernel > > Hardware Environment: > x86_64 > > Software Environment: > ? > > Problem Description: > If an application is multi-threaded, the linux kernel will append the pid > number to the core file, even if echo 0 > /proc/sys/kernel/core_uses_pid. > > >From looking at fs/exec.c, this looks intentional. > > Steps to reproduce: > Set core_uses_pid to 0 and core_pattern to core. Compile the following > program (stolen from Bug 5826). kill -SEGV it. The core file will have the > pid number appended to it. > > For those who like to copy/paste: > > cat <<EOF > threader.c > #include <pthread.h> > static void* thread_sleep(void* x) { while (1) sleep(30); } > int main(int c, char** v) { > const static int tcount = 5; > pthread_t thr[tcount]; > int i; > for (i=0; i<tcount; ++i) > pthread_create(&thr[i], NULL, thread_sleep, NULL); > while (1) > sleep(30); > return 0; > } > EOF > > gcc threader.c -o threader -l pthread > echo 0 > /proc/sys/kernel/core_uses_pid > echo core > /proc/sys/kernel/core_pattern > ulimit -c 5000 > ./threader & > sleep 1 > rm -f core* > kill -SEGV %1 > ls core* > Alan, was this intentional? Thanks.
On Iau, 2006-03-30 at 15:28 -0800, Andrew Morton wrote: > > > > gcc threader.c -o threader -l pthread > > echo 0 > /proc/sys/kernel/core_uses_pid > > echo core > /proc/sys/kernel/core_pattern > > ulimit -c 5000 > > ./threader & > > sleep 1 > > rm -f core* > > kill -SEGV %1 > > ls core* > > > > Alan, was this intentional? If I remember rightly it was the automatic behaviour for threaded core dumps before I ever added the core_pattern stuff and it goes back a long way. The alternative was that you got a mangled file where they all dumped on top of each other. Alan
Currently (at least with NPTL) a multi-threaded program core-dumps into a single file just fine.
I think we'll leave things as-is. Changing anything in this area will break things for some people.