Re: probem with dl_runtime.c

From: Paul Pluzhnikov (ppluzhnikov-nsp_at_charter.net)
Date: 10/31/04 

Date: 31 Oct 2004 13:28:44 -0800

> nikhil bhargav wrote:

> > I am running a program implementing 24 trees but i am facing a
> > problem. [...] The program executes normally but while printing
> > the last line it givs error segmentation fault [...]

> > I debugged it by GDB which shows there is some run time library
> > missing or problem in printf exercution as this problem is occuring in
> > all printfs in the program.

Huh?

> > It gave messages like some problem in dl_runtime.c which i couldnot
> > infer.

You didn't understand what gdb is telling you. So post gdb output
here and someone might be able to explain that output to you.

The most relevant part is the output from the gdb "where" command
at the time of SIGSEGV.

Tauno Voipio <tauno.voipio@iki.fi.NOSPAM.invalid> writes:

> What is the declared type of your variable 'time'?
>
> If it is not float, printf gets lost and barfs at return (see
> the format string).

While printf()ing an int or a time_t with "%f" will cause it to print
garbage, I don't think there any way in which this can cause
"printf to get lost", nor can this be the cause of a SIGSEGV.

Cheers, 

-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

Relevant Pages

  • Re: Apple security FAIL
    ... When are Apple going to get a clue about security? ... There is a related issue to do with the command line "printf" tool: ... cleanly via gdb. ...
    (uk.comp.sys.mac)
  • Re: [9fans] OS X threads + dynamic linking
    ... on the given stack. ... A gdb session running the program ... It's dying in the dynamic linker trying to resolve printf. ... char stack; ...
    (comp.os.plan9)
  • Re: More on debuggers
    ... Well, if you insert the printf() randomly, no help at all. ... A useful debugging printf() tells you, at a minimum, that the execution path through the code actually reached the printfstatement. ... I can use gdb to debug gcc programs on all of our our systems, but I try to avoid doing so, if I can, for the reasons given below. ... I'll check the value of a variable before and after execution of a statement that was supposed to change that value, and find it unchanged, because the actual storage of that value to memory has been deferred to some other location in the program. ...
    (comp.lang.c)
  • Re: phtread_create while pthread_cond_timedwait in gdb
    ... When I run this program without gdb I get the following (as ... THREAD 2: printf ... THREAD 0: Timer expired ... static void *func1; ...
    (comp.os.linux.development.apps)
  • Re: std::ostringstream, urgent
    ... > make its destructor explode? ... Are you sure it dies *before* the second printf? ... so if the program dies any buffered data may fail ... If you're using GDB: ...
    (comp.lang.cpp)