[root@10 test]# ./a.out
abc=abc, temp=abc, remain=def
Segmentation fault (core dumped)
[root@10 test]# echo $?
139
这里的139 是sig 11 处理产生coredump之后，在11这个基础上或了一个0x80，为什么要或这个值呢；
static void coredump_finish(struct mm_struct *mm, bool core_dumped)
{
struct core_thread *curr, *next;
struct task_struct *task;
spin_lock_irq(¤t->sighand->siglock);
if (core_dumped && !__fatal_signal_pending(current))
current->signal->group_exit_code |= 0x80; 这里如果原有signal是11，返回的是139
commit b9daa0066d792983da59154af3ae486eff9b9aa1
Author: Ingo Molnar mingo@elte.hu
Date: Sat Dec 14 19:44:20 2002 -0800
[PATCH] threaded coredumps, tcore-fixes-2.5.51-A0 This fixes one more threaded-coredumps detail reported by the glibc people: all threads taken down by the coredump code should report the proper exit code. We can do this rather easily via the group_exit mechanism. 'Other' threads used to report SIGKILL, which was highly confusing as the shell often displayed the 'Killed' message instead of a 'Segmentation fault' message. Another missing bit was the 0x80 bit set in the exit status for all threads, if the coredump was successful. (it's safe to set this bit in ->sig->group_exit_code in an unlocked way because all threads are artificially descheduled by the coredump code.)
还没找到0x80这个bit是什么含义；
这也就是为什么静态检查工具为什么不让用magic number的原因。
infop->cause = (status & 0x80) ? CLD_DUMPED : CLD_KILLED;
通过这个推测，可能是已经产生core文件。
