I have the output from a Solaris pstack on a core file. I don't understand how to map the numbers in the log to the parameters that were being used by the functions in question at the time of the segfault.

There seems to be more numbers in the output than the count of parameters to the function calls. Which numbers are the parameter values/addresses?

The manual is not at all helpful.

 fffffffec993a8a8 sigacthandler (b, ffffffff7fffd5e0, ffffffff7fffd300, 14b7b0, fffffffec9a86000, b) + 5c
 --- called from signal handler with signal 11 (SIGSEGV) ---
 fffffffeba4422b0 XmMessageBoxGetChild (100400, 5, 5, 0, 118, fffffffeba62e000) + e4
 000000010026a83c GetMessageDialog (101317440, 0, ffffffff7fffe130, 100420, 100400, 127a94) + 214
 000000010026ab0c _XmtDisplayMessage (101317440, 0, 1000c9510, 1011927e5, ffffffff7fffe240, 101192780) + 278
 000000010026b048 XmtDisplayInformationMsg (1000c9000, 1000c9, 100000, 2, 0, ffffffff7fffe2f8) + 44
 00000001001573ec _smog_w_alarm_post_ack_actions (101314990, 101192760, 1003a0, 1009f4970, 101317440, 100000) + 100
 000000010015819c __select_cb (101314990, ffffffff7fffe560, 101317440, 10113bfc0, 1000916d0, 10120c9d0) + 1b4
 0000000100257a04 XmtCallCallback (101314990, 100257, ffffffff7fffe560, 101183530, 0, 0) + 3c4

The only two of our application functions involved are __select_cb() and _smog_w_alarm_post_ack_actions(), the others are Motif GUI/Widget Library calls. But, looking at our function definitions:

static void __select_cb( Widget w, XtPointer call_data );
void _smog_w_alarm_post_ack_actions( Widget w, Alarm_Public_Data *alarm );

There's only two arguments to each function. I expect one of the Widget pointers is incorrect (probably pointing to a window that's already closed). I'd like to know which (if any) of those numbers maps to the actual parameter value/address to help in debugging the issue.

  • OT: Note the identifiers starting with two underscores are reserved names per the C standard: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use." – Andrew Henle Jul 6 at 12:27
  • @AndrewHenle - Agreed. This code is from a critical safety system written in 1994 (predating the linked document by more than a decade!). It uses leading underscores to indicate the external scope of the function. The idea is that functions with names beginning with an underscore are considered "module private", and double underscores are made file-private with a C static deceleration. So we're stuck continuing the patterns of our fore-coders. – Kingsley Jul 7 at 22:30

The function arguments printed by pstack are "best guess" efforts as pstack() is not a full debugger, and in some cases even a full debugger can not guarantee exact reproduction of a function's arguments without full debug data.

Solaris pstack command is built upon the libproc.so library, which provides process control and information functions. See the Illumos pstack source code for how the pstack utility retrieves the process call stack with the Pstack_iter() function.

Per the Notes section:


Determining the number and values of the arguments for each frame, as well as the values of all of the registers, is somewhat heuristic. Therefore, the values in the regs, argc, and argv arguments passed to the call-back() function are not guaranteed to be correct.

Usually it's possible to infer what the arguments are - you can see sigacthandler (b, ... right above --- called from signal handler with signal 11 (SIGSEGV) ---. In this case, hexadecimal b is decimal 11 - SIGSEGV.

Values such as 101314990 are likely heap addresses, and values similar to ffffffff7fffe560 are likely stack addresses. You can use the pmap utility to examine the process's address space to verify those values.

If you need more certainty, use a full debugger and compile with debug symbols.

  • Using dbx and the core file gives me approximately the same output. I think I might have to switch over to the GNU C toolset. – Kingsley Jul 7 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.