Re: Linux printf funny


Paul Burke <paul@xxxxxxxxxx> writes:
So, please you Linux/ GCC experienced people- what absolutely basic
item of knowledge am I lacking?

How to use the debugger ;-)

Run your app under gdb, put a hardware watchpoint on your variables,
and see when they change. Or at least put a breakpoint after the
printf, continue until it reads nan, and inspect all the variables to
see which one is wrong (if any).

Sometimes, you can't use just printf to debug code.

If you can't use gdb to inspect the variables, write a routine to
hex-dump them (i.e. cast their address to unsigned char *, dump
sizeof(var) bytes), and call it from various places to try to track
down what's happening.
.

Relevant Pages

  • Re: Inject a shared library or DLL into a running process in Linux
    ... finding local variables you have to rely on debug information, ... Using gdb you could in theory look at every single bit, ... If you start tweaking the running app, like inserting your code, you ... recovery from crashes by undoing a crashed run might not be possible. ...
    (comp.os.linux.development.system)
  • 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: gdb break
    ... Gdb watchpoints work just fine. ... int count; ... Hardware watchpoint 1: *$1 ... incr at t.c:7 ...
    (comp.unix.programmer)
  • Re: using database comparer to upgrade gdb?
    ... my app run an SQL script against the live database with all users out of the ... basically ran 3 update scripts in a row. ... > structure, I usually create a empty .gdb, then datapump the data from the ...
    (borland.public.delphi.thirdpartytools.general)
  • 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)