23.0.60; gdb not running the program first time around

23.0.60; gdb not running the program first time around

[robert marshall]

If I use gdb via M-x gdb and take the suggested default 
   gdb --annotate=3 ipsa-so
and then try to start the program, gdb just sits
there, I have to interrupt it with C-c and then run again at which
point it starts properly. See the following extract from the *gud...*
buffer:

GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run
  C-c C-cQuit          <------------- sits here until I C-c C-c
(gdb) run
Starting program: /home/robert/IPSA/IPSA+1.6/IPSAplus/ipsa-so 
[Thread debugging using libthread_db enabled]
[New Thread -1231702336 (LWP 8910)]
Qt: gdb: -nograb added to command-line options.
	 Use the -dograb option to enforce grabbing.




In GNU Emacs 23.0.60.4 (i686-pc-linux-gnu, GTK+ Version 2.12.0)
 of 2008-02-12 on rajm-laptop
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  desktop-save-mode: t
  recentf-mode: t
  show-paren-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
C-x k <return> <down> C-x k <return> C-x k <return> 
C-x k <return> C-x k <return> <f10> <return> <escape> 
x s h e l l <return> C-x 1 <help-echo> <select-window> 
. / i p s a - s o <tab> <return> <escape> x g d b <return> 
<return> r u n <return> C-c C-c <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <about-emacs> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
Setting up indent for shell type bash
setting up indent stuff
Indentation variables are now local.
Indentation setup for shell type bash
Wrote /home/rajm/.emacs.desktop.lock
Desktop: 128 buffers restored.
(No files need saving)
Completing file name...
Sole completion
For information about GNU Emacs and the GNU system, type C-h C-a.

Re: 23.0.60; gdb not running the program first time around

[Nick Roberts]

 > GNU gdb 6.6-debian
 > Copyright (C) 2006 Free Software Foundation, Inc.
 > GDB is free software, covered by the GNU General Public License, and you are
 > welcome to change it and/or distribute copies of it under certain conditions.
 > Type "show copying" to see the conditions.
 > There is absolutely no warranty for GDB.  Type "show warranty" for details.
 > This GDB was configured as "i486-linux-gnu"...
 > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
 > (gdb) run

Does it say [ready] here in the mode-line?

 >   C-c C-cQuit          <------------- sits here until I C-c C-c
 > (gdb) run
 > Starting program: /home/robert/IPSA/IPSA+1.6/IPSAplus/ipsa-so 
 > [Thread debugging using libthread_db enabled]
 > [New Thread -1231702336 (LWP 8910)]
 > Qt: gdb: -nograb added to command-line options.
 > 	 Use the -dograb option to enforce grabbing.

Do you have a .gdbinit file in this directory or $HOME?

If so, what happens if you do "gdb --annotate=3 -nx ipsa-so"?

If this works, what do you have in your .gdbinit?

If it still doesn't work, what happens if you also start with "emacs -Q"?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: 23.0.60; gdb not running the program first time around

[robert marshall]

Nick Roberts wrote:
>  > GNU gdb 6.6-debian
>  > Copyright (C) 2006 Free Software Foundation, Inc.
>  > GDB is free software, covered by the GNU General Public License, and you are
>  > welcome to change it and/or distribute copies of it under certain conditions.
>  > Type "show copying" to see the conditions.
>  > There is absolutely no warranty for GDB.  Type "show warranty" for details.
>  > This GDB was configured as "i486-linux-gnu"...
>  > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
>  > (gdb) run
>
> Does it say [ready] here in the mode-line?
>
>   
It does - I should have said that it doesn't happen every time I start 
up a gdb buffer

>  >   C-c C-cQuit          <------------- sits here until I C-c C-c
>  > (gdb) run
>  > Starting program: /home/robert/IPSA/IPSA+1.6/IPSAplus/ipsa-so 
>  > [Thread debugging using libthread_db enabled]
>  > [New Thread -1231702336 (LWP 8910)]
>  > Qt: gdb: -nograb added to command-line options.
>  > 	 Use the -dograb option to enforce grabbing.
>
> Do you have a .gdbinit file in this directory or $HOME?
>
>   

No
> If so, what happens if you do "gdb --annotate=3 -nx ipsa-so"?
>
> If this works, what do you have in your .gdbinit?
>
> If it still doesn't work, what happens if you also start with "emacs -Q"?
>
>   
I've just managed to replicate this behaviour when starting with -Q
I think it happens when I type 'run' - at the prompt (already there in 
the buffer) - when the status line still says [initializing], so it 
changes to [ready] at around the same time as I press 'enter'
ipsa-so is a fairly large file (c 90MB) and it takes around 2 sec from 
entering the 'gdb --annotate...' line to get to gdb showing [ready],  
I've just tried to do the same thing with the emacs  binary and that 
starts up far too fast to get the same problem!

Robert

Re: 23.0.60; gdb not running the program first time around

[Nick Roberts]

 > I've just managed to replicate this behaviour when starting with -Q
 > I think it happens when I type 'run' - at the prompt (already there in 
 > the buffer) - when the status line still says [initializing], so it 
 > changes to [ready] at around the same time as I press 'enter'
 > ipsa-so is a fairly large file (c 90MB) and it takes around 2 sec from 
 > entering the 'gdb --annotate...' line to get to gdb showing [ready],  
 > I've just tried to do the same thing with the emacs  binary and that 
 > starts up far too fast to get the same problem!

OK, I can see this now.  Emacs just discards the input if it's not ready, so
you don't need to do "C-c C-c" but just re-enter your input, e.g, run.
It doesn't look right, however, and I can see how it causes confusion.

Can you please try the patch below which also fixes a couple of other minor
problems at startup.  Instead of discarding the input, it should now just defer
it.  It would be helpful if you could gorilla test it and report any problems
you see as I would like to add these changes to EMACS_22_BASE for the imminent
release of Emacs 22.2

Thanks for the report.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

*** gdb-ui.el	15 Feb 2008 07:50:31 +1300	1.220
--- gdb-ui.el	15 Feb 2008 11:54:10 +1300	
*************** Emacs can't find.")
*** 137,142 ****
--- 137,144 ----
    "Non-nil when GDB generates frame-begin annotation.")
  (defvar gdb-printing t)
  (defvar gdb-parent-bptno-enabled nil)
+ (defvar gdb-ready nil)
+ (defvar gdb-early-user-input nil)
  
  (defvar gdb-buffer-type nil
    "One of the symbols bound in `gdb-buffer-rules'.")
*************** session."
*** 284,289 ****
--- 286,292 ----
  
    (gud-common-init command-line nil 'gud-gdba-marker-filter)
    (set (make-local-variable 'gud-minor-mode) 'gdba)
+   (setq comint-input-sender 'gdb-send)
  
    (gud-def gud-break  "break %f:%l"  "\C-b" "Set breakpoint at current line.")
    (gud-def gud-tbreak "tbreak %f:%l" "\C-t"
*************** session."
*** 317,322 ****
--- 320,327 ----
    (setq gdb-first-prompt t)
    (setq gud-running nil)
    (setq gdb-ready nil)
+   (setq gdb-flush-pending-output nil)
+   (setq gdb-early-user-input nil)
    (setq gud-filter-pending-text nil)
    (run-hooks 'gdb-mode-hook))
  
*************** otherwise do not."
*** 574,581 ****
    (define-key gud-minor-mode-map [left-margin C-mouse-3]
      'gdb-mouse-jump)
  
-   (setq comint-input-sender 'gdb-send)
- 
    ;; (re-)initialize
    (setq gdb-pc-address (if gdb-show-main "main" nil))
    (setq gdb-previous-frame-address nil
--- 579,584 ----
*************** otherwise do not."
*** 593,599 ****
  	gdb-pending-triggers nil
  	gdb-output-sink 'user
  	gdb-server-prefix "server "
- 	gdb-flush-pending-output nil
  	gdb-location-alist nil
  	gdb-source-file-list nil
  	gdb-error nil
--- 596,601 ----
*************** The key should be one of the cars in `gd
*** 1194,1214 ****
  (defun gdb-send (proc string)
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
!   (when gdb-ready
!       (with-current-buffer gud-comint-buffer
! 	(let ((inhibit-read-only t))
! 	  (remove-text-properties (point-min) (point-max) '(face))))
!       (if gud-running
! 	  (progn
! 	    (let ((item (concat string "\n")))
! 	      (if gdb-enable-debug (push (cons 'send item) gdb-debug-log))
! 	      (process-send-string proc item)))
! 	(if (string-match "\\\\\\'" string)
! 	    (setq gdb-continuation (concat gdb-continuation string "\n"))
! 	  (let ((item (concat gdb-continuation string
! 			      (if (not comint-input-sender-no-newline) "\n"))))
! 	    (gdb-enqueue-input item)
! 	    (setq gdb-continuation nil))))))
  
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.
--- 1196,1219 ----
  (defun gdb-send (proc string)
    "A comint send filter for gdb.
  This filter may simply queue input for a later time."
!   (if gdb-ready
!       (progn
! 	(with-current-buffer gud-comint-buffer
! 	  (let ((inhibit-read-only t))
! 	    (remove-text-properties (point-min) (point-max) '(face))))
! 	(if gud-running
! 	    (progn
! 	      (let ((item (concat string "\n")))
! 		(if gdb-enable-debug (push (cons 'send item) gdb-debug-log))
! 		(process-send-string proc item)))
! 	  (if (string-match "\\\\\\'" string)
! 	      (setq gdb-continuation (concat gdb-continuation string "\n"))
! 	    (let ((item (concat
! 			 gdb-continuation string
! 			 (if (not comint-input-sender-no-newline) "\n"))))
! 	      (gdb-enqueue-input item)
! 	      (setq gdb-continuation nil)))))
!     (push (concat string "\n")  gdb-early-user-input)))
  
  ;; Note: Stuff enqueued here will be sent to the next prompt, even if it
  ;; is a query, or other non-top-level prompt.
*************** This sends the next command (if any) to 
*** 1362,1368 ****
  	(gdb-send-item input)
        (progn
  	(setq gdb-prompting t)
! 	(gud-display-frame)))))
  
  (defun gdb-subprompt (ignored)
    "An annotation handler for non-top-level prompts."
--- 1367,1377 ----
  	(gdb-send-item input)
        (progn
  	(setq gdb-prompting t)
! 	(gud-display-frame)
! 	(setq gdb-early-user-input (nreverse gdb-early-user-input))
! 	(while gdb-early-user-input
! 	    (gdb-enqueue-input (car gdb-early-user-input))
! 	    (setq gdb-early-user-input (cdr gdb-early-user-input)))))))
  
  (defun gdb-subprompt (ignored)
    "An annotation handler for non-top-level prompts."

Re: 23.0.60; gdb not running the program first time around

[robert marshall]

Nick Roberts wrote:
>  > I've just managed to replicate this behaviour when starting with -Q
>  > I think it happens when I type 'run' - at the prompt (already there in 
>  > the buffer) - when the status line still says [initializing], so it 
>  > changes to [ready] at around the same time as I press 'enter'
>  > ipsa-so is a fairly large file (c 90MB) and it takes around 2 sec from 
>  > entering the 'gdb --annotate...' line to get to gdb showing [ready],  
>  > I've just tried to do the same thing with the emacs  binary and that 
>  > starts up far too fast to get the same problem!
>
> OK, I can see this now.  Emacs just discards the input if it's not ready, so
> you don't need to do "C-c C-c" but just re-enter your input, e.g, run.
> It doesn't look right, however, and I can see how it causes confusion.
>
> Can you please try the patch below which also fixes a couple of other minor
> problems at startup.  Instead of discarding the input, it should now just defer
> it.  It would be helpful if you could gorilla test it and report any problems
> you see as I would like to add these changes to EMACS_22_BASE for the imminent
> release of Emacs 22.2
>
> Thanks for the report.
>
>   
Your patch appears to work well so far - I'll keep an eye on it over the 
next couple of days and let you know if I see any further problems.

I've just tried
    (setq gdb-many-windows t)
- not used this before and apart from being faviourably impressed :-) 
I've come across one problem.
Our code tends to swap languages - top level is C++ which calls a c 
layer which then invokes some fortran,
when I get down to the fortran I get a debugger segmentation fault 
immediately, I don't see this issue when gdb-many-windows is nil

Do you want me to create a separate report for this - I assume there's a 
couple of issues here a gdb one and a gdb-ui.el one? Is it possible to 
run gdb within gdb in emacs?

Robert

Re: 23.0.60; gdb not running the program first time around

[Nick Roberts]

 > I've just tried
 >     (setq gdb-many-windows t)
 > - not used this before and apart from being faviourably impressed :-) 
 > I've come across one problem.
 > Our code tends to swap languages - top level is C++ which calls a c 
 > layer which then invokes some fortran,
 > when I get down to the fortran I get a debugger segmentation fault 
 > immediately, I don't see this issue when gdb-many-windows is nil

You're probably stretching the boundaries of Gdb a bit - it's not so good with
C++ but it's getting better.  Also I've found that for fortran debugging, g77
is better than gfortran as it currently generates better debug information.  I
think gfortran is the future, however, and compiles fortran 95.

 > Do you want me to create a separate report for this - I assume there's a 
 > couple of issues here a gdb one and a gdb-ui.el one?

A debugger segmentation fault means a bug in Gdb, so the report should go to
the gdb mailing list (gdb@sourceware.org).  Most users probably don't debug
inside Emacs, so you really need to find a way to reproduce it from the
command line.  Since it only happens with gdb-many-windows it is probably
caused by one of the gdb commands that Emacs runs behind the user's back
to update the extra buffers:

info stack
interpreter mi "-stack-list-locals --simple-values"

If you can get to where the debugger segmentation fault occurs from the
command line then issing these commands might trigger it.

 >                                                      Is it possible to 
 > run gdb within gdb in emacs?

I'm not sure what you mean, but certainly you can debug Gdb using Gdb in Emacs,
where Gdb just replaces ipsa-so in your scenario, and I often do this.

Also, if the problem is with Emacs, and not Gdb, then I will debug Emacs
running a Gdb session using Gdb in Emacs.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: 23.0.60; gdb not running the program first time around

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> You're probably stretching the boundaries of Gdb a bit - it's not so good with
> C++ but it's getting better.

I find gdb's _tons_ better (at debugging C++) now than even just a
couple years ago...

-Miles
-- 
Scriptures, n. The sacred books of our holy religion, as distinguished from
the false and profane writings on which all other faiths are based.

Re: 23.0.60; gdb not running the program first time around

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 16 Feb 2008 07:30:55 +0900
> Cc: emacs-pretest-bug@gnu.org, robert marshall <robert.marshall@tnei.co.uk>
> 
> Nick Roberts <nickrob@snap.net.nz> writes:
> > You're probably stretching the boundaries of Gdb a bit - it's not so good with
> > C++ but it's getting better.
> 
> I find gdb's _tons_ better (at debugging C++) now than even just a
> couple years ago...

Indeed.  As another data point, on my daytime job, we are using GDB
for debugging a large industrial-strength software package, written in
C++ using a lot of advanced C++ features.  It works just fine.

Re: 23.0.60; gdb not running the program first time around

[robert marshall]

Nick Roberts wrote:
>  > I've just tried
>  >     (setq gdb-many-windows t)
>  > - not used this before and apart from being faviourably impressed :-) 
>  > I've come across one problem.
>  > Our code tends to swap languages - top level is C++ which calls a c 
>  > layer which then invokes some fortran,
>  > when I get down to the fortran I get a debugger segmentation fault 
>  > immediately, I don't see this issue when gdb-many-windows is nil
>
> You're probably stretching the boundaries of Gdb a bit - it's not so good with
> C++ but it's getting better.  Also I've found that for fortran debugging, g77
> is better than gfortran as it currently generates better debug information.  I
> think gfortran is the future, however, and compiles fortran 95.
>
>   
As with other contributors to this thread I've found the c++ support to 
be fine - fortran appears dodgier.
We have some code which contains fortran linked lists where a points to 
b which points to c which points to a,
printing out a causes a loop I'll get a bug report sent when I can get 
an appropriate small example

>  > Do you want me to create a separate report for this - I assume there's a 
>  > couple of issues here a gdb one and a gdb-ui.el one?
>
> A debugger segmentation fault means a bug in Gdb, so the report should go to
> the gdb mailing list (gdb@sourceware.org).  Most users probably don't debug
> inside Emacs, so you really need to find a way to reproduce it from the
> command line.  Since it only happens with gdb-many-windows it is probably
> caused by one of the gdb commands that Emacs runs behind the user's back
> to update the extra buffers:
>
> info stack
> interpreter mi "-stack-list-locals --simple-values"
>
> If you can get to where the debugger segmentation fault occurs from the
> command line then issing these commands might trigger it.
>
>   
Is it possible to turn off the functionality of gdb-many-windows on the fly?
I think the bug I'm triggering may well be this one:
http://permalink.gmane.org/gmane.comp.gdb.bugs.discuss/4934
so I probably need to update gdb with a build from source

Robert

-- 
Robert A J Marshall,  
TNEI Services Ltd, 88-90 London Road, Manchester, M1 2PW 
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
tel: +44 161 615 6017; fax: +44 161 615 6001; mobile: +44 7759 688384 
web: http://IPSA-Power.com 

Re: 23.0.60; gdb not running the program first time around

[Nick Roberts]

 > Is it possible to turn off the functionality of gdb-many-windows on the fly?

M-x gdb-many-windows toggles the multiple window configuration, so just
doing it again will turn it off (if that's what you mean).

 > I think the bug I'm triggering may well be this one:
 > http://permalink.gmane.org/gmane.comp.gdb.bugs.discuss/4934
 > so I probably need to update gdb with a build from source

If you look at http://sourceware.org/cgi-bin/gnatsweb.pl and view problem
report #2412, you can see from the audit trail that it has indeed been fixed in
CVS.  Note Gdb 6.8 will have this fix and should be available shortly, if you
don't want to build from source.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: 23.0.60; gdb not running the program first time around

[robert marshall]

robert marshall wrote:
> Nick Roberts wrote:
>>  
>>
>> Can you please try the patch below which also fixes a couple of other 
>> minor
>> problems at startup.  Instead of discarding the input, it should now 
>> just defer
>> it.  It would be helpful if you could gorilla test it and report any 
>> problems
>> you see as I would like to add these changes to EMACS_22_BASE for the 
>> imminent
>> release of Emacs 22.2
>>
>> Thanks for the report.
>>
>>   
> Your patch appears to work well so far - I'll keep an eye on it over 
> the next couple of days and let you know if I see any further problems.
>
Just to confirm that the patch still works ok - the only issue where it 
appears to get confused - though I've not verified whether the pre-patch 
code also had this issue - is when gdb crashes - then a M-x gdb restarts 
the debugger but doesn't produce a prompt until you press return

Robert

-- 
Robert A J Marshall,  
TNEI Services Ltd, 88-90 London Road, Manchester, M1 2PW 
Registered in England & Wales No. 03891836,
Registered office:  Milburn House, Dean Street, Newcastle upon Tyne, NE1 1LE
tel: +44 161 615 6017; fax: +44 161 615 6001; mobile: +44 7759 688384 
web: http://IPSA-Power.com 

Re: 23.0.60; gdb not running the program first time around

[Nick Roberts]

 > Just to confirm that the patch still works ok - the only issue where it 
 > appears to get confused - though I've not verified whether the pre-patch 
 > code also had this issue - is when gdb crashes - then a M-x gdb restarts 
 > the debugger but doesn't produce a prompt until you press return

OK, thanks for getting back.  I've only applied the patch to trunk (which I
think you have anyway) because it causes problems to gud-gdb which need to be
investigated.

Gdb crashing should be a rare occurance but the problem coincidentally seems
to be solved by Stefan Monnier's recent patch.  If you're updating in CVS
you can get it that way, otherwise it's reproduced below.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


--- orig/lisp/progmodes/gdb-ui.el
+++ mod/lisp/progmodes/gdb-ui.el
@@ -150,7 +150,7 @@
 (defvar gdb-prompting nil
   "True when gdb is idle with no pending input.")
 
-(defvar gdb-output-sink 'user
+(defvar gdb-output-sink nil
   "The disposition of the output of the current gdb command.
 Possible values are these symbols:
 
@@ -317,6 +317,7 @@
   (local-set-key "\C-i" 'gud-gdb-complete-command)
   (setq comint-prompt-regexp "^(.*gdb[+]?) *")
   (setq paragraph-start comint-prompt-regexp)
+  (setq gdb-output-sink 'user)
   (setq gdb-first-prompt t)
   (setq gud-running nil)
   (setq gdb-ready nil)