turning off "backtraces" in gcc

This is a discussion on turning off "backtraces" in gcc within the Linux Programming forums, part of the Platform Specific Boards category; Can I turn off the "backtracing" that appears after some gcc errors?...

  1. #1
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300

    turning off "backtraces" in gcc

    Can I turn off the "backtracing" that appears after some gcc errors?
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  2. #2
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    Continuation of this: munmap_chunk(): invalid pointer

    You could compile with a custom-built version of glibc, I guess. Other than that, see my other suggestion.

    [edit] Why do you want to? Was my guess correct, more or less? [/edit]
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  3. #3
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    What is the advantage of doing this, MK27--if that is your real name... which I am betting it is.

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300

    son of 54

    What is the advantage of doing this, MK27--if that is your real name... which I am betting it is.

    Because the output doesn't tell me much other than that I should learn to use GDB or something. However, if I'm hack debugging by moving a "puts" statement around (which eventually solved my last fiasco), all that scrolling is a drag. That it can't be turned off is UNBELIEVABLE.

    regarding my real name -- now that's a secret -- but you're right. Don't tell anyone, I hear they come in multiples!

    and thanks dwk for your other suggestion about 2&>/dev/null (I think that's how it's done)
    Last edited by MK27; 09-05-2008 at 05:13 PM. Reason: dwk
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,352
    Quote Originally Posted by MK27 View Post
    Because the output doesn't tell me much other than that I should learn to use GDB or something. However, if I'm hack debugging by moving a "puts" statement around (which eventually solved my last fiasco), all that scrolling is a drag. That it can't be turned off is UNBELIEVABLE.
    This thread is a few days old, I know...

    The only way I can immediately imagine that a backtrace could be printed during a program crash is if the crash signal was trapped by the C library. This would imply that you could prevent the backtrace dump by overriding the crash signal handler. There are several ways a program could crash, the most likely being SIGSEGV, SIGBUS, SIGFPE, or SIGILL. Try resetting these handlers back to their defaults and see if the dumps go away.

    Code:
    #include <signal.h>
    
    signal(SIGSEGV, SIG_DFL);
    signal(SIGBUS, SIG_DFL);
    signal(SIGFPE, SIG_DFL);
    signal(SIGILL, SIG_DFL);
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    thanks brewbuck, i will remember this the next time it bugs me.

    I'm a little surprised you have to "imagine" a backtrace occuring, tho, as if it were a strange event? A "double free" will do it with my out-of-the-fedora-7 box gcc 4.12...
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  7. #7
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,352
    Quote Originally Posted by MK27 View Post
    I'm a little surprised you have to "imagine" a backtrace occuring, tho, as if it were a strange event? A "double free" will do it with my out-of-the-fedora-7 box gcc 4.12...
    A crash and a backtrace are not the same. Crashes are not out of the ordinary. But a backtrace being printed is not something that should normally happen. The C library has obviously been modified to catch the crash signal and dump a backtrace.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Quick Compilation Question
    By chacham15 in forum C Programming
    Replies: 10
    Last Post: 10-12-2008, 08:15 PM
  2. Profiler Valgrind
    By afflictedd2 in forum C++ Programming
    Replies: 4
    Last Post: 07-18-2008, 09:38 AM
  3. Replies: 4
    Last Post: 09-02-2007, 08:47 PM
  4. Compiles on gcc 3.3 but not on gcc 4.0.3
    By cunnus88 in forum C++ Programming
    Replies: 5
    Last Post: 03-29-2007, 12:24 PM
  5. gcc
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 10-22-2003, 03:46 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21