Re: SIGSEGV informations

From: Paul Pluzhnikov (ppluzhnikov-nsp_at_charter.net)
Date: 08/18/05

  • Next message: Paul Pluzhnikov: "Re: SIGSEGV informations" 
    Date: Wed, 17 Aug 2005 20:43:27 -0700

    "Serge Wenger" <serge_wenger001@hotmail.com> writes:

    > Thank for the suggestion.

    Please do not top-post:
     http://catb.org/~esr/jargon/html/T/top-post.html

    > It was not what I hope. I search for a method to give the call stack when an
    > error occurs on a customer machine, not only on development machine.

    The exact same method works on the customer machine.
    Just ask customer to run your program under gdb.

    There are also routines in glibc, which allow you to print crash
    stack trace: backtrace() and backtrace_symbols() [do "info libc"
    -> Backtraces].

    You'll have to install a SIGSEGV handler, print the stack trace
    and abort(). Further details here:
     http://groups.google.com/group/comp.os.linux.development.apps/msg/0e4ff8fb2959797a

    Cheers, 

    -- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
  • Next message: Paul Pluzhnikov: "Re: SIGSEGV informations"

    Relevant Pages

    • Re: SIGSEGV informations
      ... The exact same method works on the customer machine. ... backtrace() and backtrace_symbols[do "info libc" ... You'll have to install a SIGSEGV handler, print the stack trace ... In order to understand recursion you must first understand recursion. ...
      (comp.os.linux.misc)
    • Re: Weird crash in in _nv000029gl () from /usr/lib/libGL.so.1
      ... it follows the gdb's backtrace: ... The interesting part of your stack trace is the 'calloc'. ... In order to understand recursion you must first understand recursion. ...
      (comp.os.linux.development.apps)