Timeline for sigaction(7): semantics of siginfo_t's si_code member
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 17, 2013 at 17:52 | comment | added | user732 | Getting a core dump allowed me to figure out the underlying problem: a data race condition, where a file could get created and then noticed by my program. The file could get deleted before my program tried to open it. I didn't handle ENOENT correctly, causing problems up the call stack. | |
| Apr 17, 2013 at 17:50 | vote | accept | CommunityBot | ||
| Apr 11, 2013 at 9:08 | history | tweeted | twitter.com/#!/StackUnix/status/322274915770302464 | ||
| Apr 5, 2013 at 16:47 | comment | added | James Sneeringer | The kernel logs when a processes is killed by oom-killer. Even if you can't inspect /var/log, you should be able to access the kernel log buffer with the dmesg command so you can rule this possibility out. | |
| Apr 5, 2013 at 4:54 | answer | added | Jonathan Ben-Avraham | timeline score: 7 | |
| Apr 5, 2013 at 0:06 | review | Close votes | |||
| Apr 5, 2013 at 5:08 | |||||
| Apr 4, 2013 at 21:48 | comment | added | jordanm | a segfault should produce a core dump if the ulimit allows it. Inspect the core dump with gdb. | |
| Apr 4, 2013 at 21:24 | history | asked | user732 | CC BY-SA 3.0 |