bug#5060: More debugging information

bug#5060: More debugging information

[Michael Welsh Duggan]

Shortly before the failure occurs, gdb-frame-handler is called.  In the
context of the failure, the frame variable is set to:

  ((line . "29") (file . "longjmp.c") (func . "__libc_siglongjmp") 
   (addr . "0xb79ef6c1") (level . "0"))

gdb-selected-file is nil, since there is no 'fullname.
gdb-selected-line gets 29.  So, gud-last-frame is '(nil . 29).
gud-display-frame is then called, which calls gud-display-line with the
args from gud-last frame.  I.e., (gud-display-frame nil 29).  This nil
is what is later causing problems when gud-find-file is called.

My guess is that gud-display-frame should not be called if
gdb-selected-file is nil.  But I do not understand the code well enough
to know that this is the case.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

bug#5060: More debugging information

[Nick Roberts]

 > Shortly before the failure occurs, gdb-frame-handler is called.  In the
 > context of the failure, the frame variable is set to:
 > 
 >   ((line . "29") (file . "longjmp.c") (func . "__libc_siglongjmp") 
 >    (addr . "0xb79ef6c1") (level . "0"))
 > 
 > gdb-selected-file is nil, since there is no 'fullname.
 > gdb-selected-line gets 29.  So, gud-last-frame is '(nil . 29).
 > gud-display-frame is then called, which calls gud-display-line with the
 > args from gud-last frame.  I.e., (gud-display-frame nil 29).  This nil
 > is what is later causing problems when gud-find-file is called.
 > 
 > My guess is that gud-display-frame should not be called if
 > gdb-selected-file is nil.  But I do not understand the code well enough
 > to know that this is the case.

That sounds right.  Using gdb-frame-handler to get the current line is a bit of
a hack because gdb doesn't always print the location when it stops.  This code
doesn't look quite right.  Does the patch below work?

-- 
Nick                                           http://users.snap.net.nz/~nickrob


*** gdb-mi.el.~1.53.~	2009-11-03 19:06:46.000000000 +1300
--- gdb-mi.el	2009-11-29 00:41:01.000000000 +1300
*************** overlay arrow in source buffer."
*** 3754,3762 ****
        (setq gdb-frame-number (bindat-get-field frame 'level))
        (setq gdb-frame-address (bindat-get-field frame 'addr))
        (let ((line (bindat-get-field frame 'line)))
!         (setq gdb-selected-line (or (and line (string-to-number line))
!                                     nil)) ; don't fail if line is nil
!         (when line ; obey the current file only if we have line info
            (setq gud-last-frame (cons gdb-selected-file gdb-selected-line))
            (gud-display-frame)))
        (if gud-overlay-arrow-position
--- 3754,3761 ----
        (setq gdb-frame-number (bindat-get-field frame 'level))
        (setq gdb-frame-address (bindat-get-field frame 'addr))
        (let ((line (bindat-get-field frame 'line)))
!         (setq gdb-selected-line (and line (string-to-number line)))
!         (when (and gdb-selected-file gdb-selected-line)
            (setq gud-last-frame (cons gdb-selected-file gdb-selected-line))
            (gud-display-frame)))
        (if gud-overlay-arrow-position

bug#5060: More debugging information

[Michael Welsh Duggan]

nickrob@snap.net.nz (Nick Roberts) writes:

>  > Shortly before the failure occurs, gdb-frame-handler is called.  In the
>  > context of the failure, the frame variable is set to:
>  > 
>  >   ((line . "29") (file . "longjmp.c") (func . "__libc_siglongjmp") 
>  >    (addr . "0xb79ef6c1") (level . "0"))
>  > 
>  > gdb-selected-file is nil, since there is no 'fullname.
>  > gdb-selected-line gets 29.  So, gud-last-frame is '(nil . 29).
>  > gud-display-frame is then called, which calls gud-display-line with the
>  > args from gud-last frame.  I.e., (gud-display-frame nil 29).  This nil
>  > is what is later causing problems when gud-find-file is called.
>  > 
>  > My guess is that gud-display-frame should not be called if
>  > gdb-selected-file is nil.  But I do not understand the code well enough
>  > to know that this is the case.
>
> That sounds right.  Using gdb-frame-handler to get the current line is
> a bit of a hack because gdb doesn't always print the location when it
> stops.  This code doesn't look quite right.  Does the patch below
> work?

It does work.  I will be submitting a followup misfeature as a separate
bug.

-- 
Michael Welsh Duggan
(md5i@md5i.com)