Re: Nautilus debugging tips?

[Dave Camp <dave novell com>]

Two More: 

* Setting the NAUTILUS_DEBUG environment variable to 1 will make all
g_log warnings and criticals stop in gdb, and will stop nautilus from
respawning.

* If you don't want g_log to break in the debugger but you want nautilus
to stop respawning, you can unset SESSION_MANAGER in the shell you're
running nautilus from.

-dave

On Wed, 2004-10-13 at 11:19 +0200, Alexander Larsson wrote:
> 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! 
>