unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#5060: More debugging information
@ 2009-11-28  4:07 Michael Welsh Duggan
  2009-11-29  0:36 ` Nick Roberts
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Welsh Duggan @ 2009-11-28  4:07 UTC (permalink / raw)
  To: 5060

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)





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#5060: More debugging information
  2009-11-28  4:07 bug#5060: More debugging information Michael Welsh Duggan
@ 2009-11-29  0:36 ` Nick Roberts
  2009-11-30  3:59   ` Michael Welsh Duggan
  0 siblings, 1 reply; 3+ messages in thread
From: Nick Roberts @ 2009-11-29  0:36 UTC (permalink / raw)
  To: Michael Welsh Duggan, 5060

 > 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





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#5060: More debugging information
  2009-11-29  0:36 ` Nick Roberts
@ 2009-11-30  3:59   ` Michael Welsh Duggan
  0 siblings, 0 replies; 3+ messages in thread
From: Michael Welsh Duggan @ 2009-11-30  3:59 UTC (permalink / raw)
  To: Nick Roberts; +Cc: 5060

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)





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2009-11-30  3:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-28  4:07 bug#5060: More debugging information Michael Welsh Duggan
2009-11-29  0:36 ` Nick Roberts
2009-11-30  3:59   ` Michael Welsh Duggan

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).