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