RE: different behavior under gdb - how to track this down?

[Skip Montanaro]

    Margaret> printf's -- it's that or your friendly local kernel debugger.
    Margaret> Or examine the core file, see what you can figure out, read
    Margaret> the code, blah, blah.

I've been trying the Python equivalent of printf (inserting prints or
turning on statement-level tracing).  With a high-level language like Python
though, you can execute tens to thousands of C source lines per line of
Python that is executed, so the granularity isn't quite good enough.  Gtk+
is a monstrous package, so inserting printfs into it and recompiling is very
time-consuming.  Most of PyGtk is automatically generated, so it's not a
real good candidate for printf insertion either.  Ideally, I would have just
set some breakpoints in gdb and attached commands to them (that's my usual
printf insertion technique), but that obviously ain't gonna cut it here.

I've also tried the core file path, but like I said, that only gets me
post-mortem info.  What perplexes me is why g_log gets called when run under
gdb (with values that suggest it shouldn't be called).  I was hoping that
maybe there was some problem with gdb and someone would say, "yeah, that's a
known bug in gdb. just apply this frobnicator patch..." :-)

Thx,

Skip

    -----Original Message-----
    From: address@hidden [mailto:address@hidden
    Sent: Tuesday, October 30, 2001 2:59 PM
    To: address@hidden
    Subject: different behavior under gdb - how to track this down?


    I am trying to debug a segmentation violation in a complex system
    (Python, Gtk+, PyGtk, all from current CVS).  All code is running on a
    Mandrake 8.0 system built with gcc 2.96.  Unfortunately, if I run the
    Python script under gdb (20011010-gdb+dejagnu), the program clearly
    behaves differently than when it is run standalone.  For example,
    various Gtk warnings are displayed when it's run under gdb, but not
    when run standalone.  If I set a breakpoint in g_log, then pop up one
    stack frame, I find execution at



        g_return_val_if_fail (default_value >= minimum &&

                              default_value <= maximum, NULL);



    When I examine default_value, minimum and maximum, they all have
    acceptable values (0.5, 0.0 and 1.0, respectively), so g_log shouldn't
    be called.



    With all the (apparently) spurious Gtk warnings, the program never
    gets to the place where the segmentation violation occurs.  I can get
    a backtrace from the core file, but obviously can't step my way into
    the problem, only examine it after the fact.



    Any idea how to debug this problem?



    Thx,



    --

    Skip Montanaro

    address@hidden

    _______________________________________________
    Bug-gdb mailing list
    address@hidden
    http://mail.gnu.org/mailman/listinfo/bug-gdb