segfaults
Lars T. Kyllingstad
public at kyllingen.NOSPAMnet
Mon May 3 23:58:43 PDT 2010
On Mon, 03 May 2010 20:32:03 -0500, Ellery Newcomer wrote:
> On 05/03/2010 06:08 PM, Graham Fawcett wrote:
>>
>> [...]
>>
>> And "(139& 0x0000ff00)>>> 8" evaluates to 0. I am not sure why it's
>> not simply returning the raw status-code, though, and only on Posix
>> systems -- it must be a Posix-ism I'm not familiar with.
>>
>> Graham
>
> I'm on fedora, and yeah, I guess it's a posixism. investigation yields
> lower 16 bits is coredump flag and signal code upper 16 bits is status
> code
That hardcoded bit shift in std.process is really ugly, and hides what is
going on. Here's the correct way to analyse POSIX status codes:
import core.sys.posix.sys.wait;
...
if (WIFEXITED(status))
writeln("Process exited with code ", WEXITSTATUS(status));
else if (WIFSIGNALED(status))
writeln("Process terminated by signal ", WTERMSIG(status));
In your case the segfault would cause SIGSEGV (signal 11) to be sent to
the process, and the the above test would print "Process terminated by
signal 11".
See "man wait" for more info.
> I tell ya, working with D, ya learn something new every day [while
> implementing crap that the provided libraries should handle on their
> own...]
std.process is currently undergoing a complete redesign, so the current
situation should improve in the near future. :)
-Lars
More information about the Digitalmars-d-learn
mailing list