Re: Nautilus debugging tips?

[Alexander Larsson <alexl redhat com>]

On Tue, 2004-10-12 at 22:05 -0700, Jimmy Do wrote:
> Hey everyone,
> 
> Initially, one of the toughest things about contributing to Nautilus
> was learning how to debug effectively. I've developed a pattern of
> debugging that works for me, but I was wondering if anyone has any
> further advice.
> 
> Right now, here's what I do:
> 1. find a bug
> 2. locate the part of the source where I suspect the bug might be
> 3. look through the code and understand its paths of execution
> 4. open up a terminal
> 5. run: 'ps axu | grep nautilus' to get Nautilus' pid
> 6. run: 'gdb nautilus <nautilus pid>' to debug the currently running
> nautilus process
> 7. debug by placing lots of breakpoints
> 8. edit the source code
> 9. compile & install the updated nautilus with 'make && make install'
> 10. restart nautilus: 'nautilus --quit'
> 11. repeat steps 5-10 until the bug is fixed
> 
> Is this what most Nautilus developers do, or am I doing stuff the hard way? :)
> 
> Thanks for any advice! I really appreciate it.

Some hints:

* You don't have to make install each time. You can run nautilus from
the build tree, just start src/nautilus. This is a libtool wrapper
script that makes sure you use the libraries in the build-tree. (When
you change e.g. a bonoboui xml file you have to install of course.)
* You don't have to rebuild all of nautilus each time. Often rebuilding
by running make in libnautilus-private/ or src/ is enough
* You don't have to connect to nautilus like that. Just run nautilus in
the debugger like: "gdb nautilus" and then "run <arguments>". However,
this requires nautilus to not already be running. You can get nautilus
out of the session (so it doesn't restart automatically) by using
"gnome-session-remove nautilus".
* When you want to understand a more complicated behaviour, I often use
printf debugging. Just sprinkle g_print ("foo: doing bar\n") in the code
and then watch the output when you run nautilus and do the think you're
debugging.
* strace is a useful tool at times. Use "-f" to follow into threads, "-
tt" to get good timestamps and "-o logfile" to avoid mixing stdout and
the trace.
* Sometimes when you strace, you want to know when something happens.
Just put in a call like access("Doing gazonk", 0) in the code. It'll
show up with the string in the trace.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a maverick drug-addicted vampire hunter on the hunt for the last specimen 
of a great and near-mythical creature. She's a blind foul-mouthed socialite on 
her way to prison for a murder she didn't commit. They fight crime!