Description of problem: Summary says it all. This can be seen e.g. on the way grep operates: $ grep /dev/null -e '' $ env POSIXLY_CORRECT=1 grep /dev/null -e '' grep: -e: No such file or directory grep: : No such file or directory $ operf grep /dev/null -e '' operf: Profiler started grep: -e: No such file or directory grep: : No such file or directory profiled app exited with the following status: 2 Profiling done. Version-Release number of selected component (if applicable): $ rpm -q oprofile oprofile-0.9.9-5.54.gb7e9a57.fc21.x86_64 How reproducible: Always. Additional info: I don't suppose it's desirable to simply unset POSIXLY_CORRECT before the profiled process is launched, because in a scenario such as this: $ env POSIXLY_CORRECT=1 operf foo bar baz ... the variable should still be seen by foo. It's just when operf sets the variable for whatever internal purposes that it shouldn't leak out.
See this being set explicitly in operf.cpp: static int _process_operf_and_app_args(int argc, char * const argv[]) { bool keep_trying = true; int idx_of_non_options = 0; setenv("POSIXLY_CORRECT", "1", 0); Also see this being similar setenv in ocount and opjitconv. All three of them appear to be using this to affect the behavior of getopt_long. It looks like probably would need save and restore POSIXLY_CORRECT.
Could you test the following scratch build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=8563409 It has a patch to unset the POSIXLY_CORRECT if it wasn't set before.
Works. When set on the outside, POSIXLY_CORRECT falls through to the traced binary. When unset, it doesn't leak from operf.
oprofile-0.9.9-8.54.gb7e9a57.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/oprofile-0.9.9-8.54.gb7e9a57.fc21
oprofile-0.9.9-8.54.gb7e9a57.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.