Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 14040 Details for
Bug 23649
sparc32(sun4m)-SMP, two threads simultaneously in '-lm' heavily => SegFault
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
Simplest stand-alone failure demo I can create. Compile as shown.
skel.c (text/plain), 3.50 KB, created by
Ferris McCormick (RETIRED)
on 2003-06-30 09:24:41 UTC
(
hide
)
Description:
Simplest stand-alone failure demo I can create. Compile as shown.
Filename:
MIME Type:
Creator:
Ferris McCormick (RETIRED)
Created:
2003-06-30 09:24:41 UTC
Size:
3.50 KB
patch
obsolete
>/* skel.c > * Minimal SegFault generator for math threads SS20-SMP, > * bug #23649 > * > * gcc -O2 -o skel skel.c -lm -lpthread > * skel > * > * Should fail pretty much instantly (within 60 seconds). > * > * Empirically, to get the failure you need the mutual lock/unlock > * steps. And to generate the self-contained failure, you need > * two threads in libm. But one thread seems to be sufficient > * if you start something like this on an already saturated system. > * > * I have not been able to simplify the problem further, but this > * program is already about as simple as you can get yet still > * do anything at all with threads. > * > * With this version, the mutex semantics are verifiably > * correct: A mutex will be unlocked by the main thread > * if and only if the main thread just locked it with a > * trylock attempt. Otherwise, the mutex is owned by > * its cosine computer. > * (Formally, it is if(trylock_succeeds) unlock_it;) > * > * As suspected, -gdb- seems to be useless in this case, because > * 1. The program will not fail with the debugger in use; > * 2. If you let the program generate a core file on failure, > * it cannot be analyzed (at least not by someone like me > * who doesn't know how to use gdb). > * > * > * As with previous variations on this theme, this program would appear > * to run on sparc64-SMP until it melts the CPUs. > * On my SS20-SMP, I get the segment fault within about 45 seconds very > * consistently. > * > * 30.vi.03, FEM > * > */ > >#include <stdio.h> >#include <math.h> >#include <pthread.h> > >pthread_mutex_t global[2] = { > PTHREAD_MUTEX_INITIALIZER, > PTHREAD_MUTEX_INITIALIZER, >}; > > >struct parm { > int ac; > char ** av; >}; > >void * >do_cos(void * mutex_number_indicator) { > /* Do nothing but use cycles in the cosine function, > * periodically doing a double mutex dance with the > * main thread. > * 1. The dance seems necessary to generate a failure, > * 2. The loop count (500) is arbitrary, but for me it > * seems to minimize MTBF. > * > * */ > double d = 0.0; > int k; > int m; > int stat; > m = ( (struct parm*) mutex_number_indicator) -> ac; > fprintf(stderr,"Enter cosine redliner referencing mutex global[%d]\n",m); > while(1) { > stat = pthread_mutex_lock(&global[m] ); > if(stat) { > fprintf(stderr,"mutex_lock returned error status %d on global[%d]\n",stat,m); > exit(stat); > } > for(k=0; k < 500; ++k) {d = cos(d);} > stat = pthread_mutex_unlock(&global[m]); > if(stat) { > fprintf(stderr,"mutex_unlock returned error status %d on global[%d]\n",stat,m); > exit(stat); > } > } > return 0; /* NOT REACHED */ >} >int >main(int argc, char * argv[]) { > struct parm p1, p2 ; > pthread_t thr_cos1, thr_cos2; > int k, stat; > > pthread_mutex_init(&global[0],NULL); /* Superfluous */ > pthread_mutex_init(&global[1],NULL); /* Superfluous */ > > p1.ac = 0; > p2.ac = 1; > p1.av = p2.av = (char**) 0; > > fprintf(stderr,"Start first math(cos) thread\n"); > pthread_create(&thr_cos1, NULL, do_cos, (void*) &p1); > fprintf(stderr,"Start second math(cos) thread\n"); > pthread_create(&thr_cos2, NULL, do_cos, (void*) &p2); > while(1) { > for(k=0; k < 2; k++) { > /* Try to grab each mutex in turn. If we get it, > * immediately give it back. > */ > stat = pthread_mutex_trylock (&global[k]); > if(stat==0) {pthread_mutex_unlock(&global[k]);} > } > } > return (-1); /* BETTER NOT BE REACHED */ >}
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 23649
:
13968
| 14040