Difference between revisions of "Known Issues"
Jump to navigation
Jump to search
| Line 5: | Line 5: | ||
* Spawning more application threads than simulated cores. Sniper does not model an OS or scheduler, so each core runs exactly one thread. When threads end, their core becomes free again to run new threads, but at no point in time can there be more threads active than the number of cores specified with the <code>-n</code> command-line parameter. | * Spawning more application threads than simulated cores. Sniper does not model an OS or scheduler, so each core runs exactly one thread. When threads end, their core becomes free again to run new threads, but at no point in time can there be more threads active than the number of cores specified with the <code>-n</code> command-line parameter. | ||
| − | * | + | * If your application is expected to encounter and recover from instruction exceptions, such as SIGFPE, SIGSEGV or other synchronous signals, you'll need to add the <code>-g --general/enable_signals=true</code> command-line parameter. |
Latest revision as of 09:47, 16 December 2011
Unsupported Application Behavior
Sniper does currently not support the following application behavior:
- Spawning more application threads than simulated cores. Sniper does not model an OS or scheduler, so each core runs exactly one thread. When threads end, their core becomes free again to run new threads, but at no point in time can there be more threads active than the number of cores specified with the
-ncommand-line parameter.
- If your application is expected to encounter and recover from instruction exceptions, such as SIGFPE, SIGSEGV or other synchronous signals, you'll need to add the
-g --general/enable_signals=truecommand-line parameter.
