wrong-type-argument in gud-tooltip-mode

wrong-type-argument in gud-tooltip-mode

[Herbert Euler]

In emacs-unicode-2, toggling gud-tooltip-mode results in an error
(wrong-type-argument stringp nil) in `gdb-create-define-alist'.  This
function is invoked by `gud-tooltip-mode' on every buffer that
satisfies the conditions specified in its definition:

[definition of `gud-tooltip-mode']

            (dolist (buffer (buffer-list))
              (unless (eq buffer gud-comint-buffer)
                (with-current-buffer buffer
                  (when (and (memq gud-minor-mode '(gdbmi gdba))
                             (not (string-match "\\`\\*.+\\*\\'"
                                                (buffer-name))))
                    (make-local-variable 'gdb-define-alist)
                    (gdb-create-define-alist)
                    (add-hook 'after-save-hook
                              'gdb-create-define-alist nil t))))))

Unfortunately, the regular expression here is not complete.  Buffers
whose name start with a space character do not visit files, but they
satisfy the above conditions too.  Hence `gdb-create-define-alist' is
invoked on these buffers too, which causes the error, when
`gdb-create-define-alist' checks the existence of the file that
current buffer visits.

I did not try the HEAD version, but since the definition of
`gud-tooltip-mode' is the same as that in the emacs-unicode-2 branch,
I guess this bug exists in HEAD too.

Regards,
Guanpeng Xu
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: wrong-type-argument in gud-tooltip-mode

[Herbert Euler]

> Buffers whose name start with a space character do not visit files,

Sorry, this is not precise.  I meant the buffers whose names looks like
" *string-output*", " *Echo Area 0*" etc.

Regards,
Guanpeng Xu
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: wrong-type-argument in gud-tooltip-mode

[Nick Roberts]

Herbert Euler writes:
 > 
 > > Buffers whose name start with a space character do not visit files,
 > 
 > Sorry, this is not precise.  I meant the buffers whose names looks like
 > " *string-output*", " *Echo Area 0*" etc.

I don't follow, gud-tooltip-mode is not trying to match these buffer names.
They should be excluded because the value of gud-minor-mode should be nil
in them.  What value do thay have for gud-minor-mode?

Clearly there's a bug but I think it's elsewhere.

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

RE: wrong-type-argument in gud-tooltip-mode

[Herbert Euler]

>>> Buffers whose name start with a space character do not visit files,
>> 
>> Sorry, this is not precise. I meant the buffers whose names looks like
>> " *string-output*", " *Echo Area 0*" etc.
>
> I don't follow, gud-tooltip-mode is not trying to match these buffer names.
> They should be excluded because the value of gud-minor-mode should be nil
> in them. What value do thay have for gud-minor-mode?
>
> Clearly there's a bug but I think it's elsewhere.

I do not follow that, too.  I was too anxious to post the description
so that I posted it without careful checking of the situation.

The buffer that satisfies both the two predicates there is the buffer
" *partial-output-*", the value of its variable `gud-minor-mode' is
copied from the one inside `gud-comint-buffer', in my case it is
'gdba.  Its name, " *partial-output-*", does not match the regular
expression too.  And of course it does not visit any file.

This is where the bug is.  Since buffers like " *partial-output-*" are
created with the function `gdb-get-buffer-create', perhaps we should
prevent all buffers that can be created with this function, besides
the ones prevented by the existing predicates.

Regards,
Guanpeng Xu
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: wrong-type-argument in gud-tooltip-mode

[Nick Roberts]

 > The buffer that satisfies both the two predicates there is the buffer
 > " *partial-output-*", the value of its variable `gud-minor-mode' is
 > copied from the one inside `gud-comint-buffer', in my case it is
 > 'gdba.  Its name, " *partial-output-*", does not match the regular
 > expression too.  And of course it does not visit any file.

OK, I see I added a space in Dec 2006 to make the buffer invisible in
list-buffers but I still don't see why there is an error because
gdb-create-define-alist only uses the file as input if one exists:

              ...
	      (call-process shell-file-name
			    (if (file-exists-p file) file nil)
			    (concat gdb-cpp-define-alist-program " "
				    gdb-cpp-define-alist-flags))...

Also I've tried to reproduce the error in emacs-unicode-2 and on the trunk
but can't.

Can you please set debug-on-error to t, recreate the error and post the
lisp backtrace here?

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

RE: wrong-type-argument in gud-tooltip-mode

[Herbert Euler]

>> The buffer that satisfies both the two predicates there is the buffer
>> " *partial-output-*", the value of its variable `gud-minor-mode' is
>> copied from the one inside `gud-comint-buffer', in my case it is
>> 'gdba. Its name, " *partial-output-*", does not match the regular
>> expression too. And of course it does not visit any file.
>
> OK, I see I added a space in Dec 2006 to make the buffer invisible in
> list-buffers but I still don't see why there is an error because
> gdb-create-define-alist only uses the file as input if one exists:
>
>  ...
>  (call-process shell-file-name
>  (if (file-exists-p file) file nil)
>  (concat gdb-cpp-define-alist-program " "
>  gdb-cpp-define-alist-flags))...
>
> Also I've tried to reproduce the error in emacs-unicode-2 and on the trunk
> but can't.

It is easy to reproduce now, even without gdb.  Since the buffer 
" *partial-output-*" does not visit any file, the FILE argument provided
to `file-exists-p' will be nil.  However,

  (file-exists-p nil)
  error--> Wrong type argument: stringp, nil

That is the error.

> Can you please set debug-on-error to t, recreate the error and post the
> lisp backtrace here?

Starting with the -Q option, I got

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  file-exists-p(nil)
  gdb-create-define-alist()
  gud-tooltip-mode(toggle)
  call-interactively(gud-tooltip-mode t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)

Regards,
Guanpeng Xu
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: wrong-type-argument in gud-tooltip-mode

[Nick Roberts]

 > > Also I've tried to reproduce the error in emacs-unicode-2 and on the trunk
 > > but can't.
 > 
 > It is easy to reproduce now, even without gdb.  Since the buffer 
 > " *partial-output-*" does not visit any file, the FILE argument provided
 > to `file-exists-p' will be nil.  However,
 > 
 >   (file-exists-p nil)
 >   error--> Wrong type argument: stringp, nil
 > 
 > That is the error.
 
Yes, that is easy!  I can see it in the *Messages* buffer now.  I was fooled
because I thought I'd see any error in the mini-buffer.  I'm a bit confused
about when errors do get printed there now.

How about the patch below.  There seems to be no point in running call-process
with no input file.  I could probably also remove the string-match for
"\\`\\*.+\\*\\'" in gud-tooltip-mode too, as these buffers have no files
associated with them anyway.

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


*** gdb-ui.el.~1.218.~	2008-01-23 17:34:20.000000000 +1300
--- gdb-ui.el	2008-01-27 23:06:38.000000000 +1300
*************** otherwise do not."
*** 435,445 ****
  	 (output
  	  (with-output-to-string
  	    (with-current-buffer standard-output
! 	      (call-process shell-file-name
! 			    (if (file-exists-p file) file nil)
  			    (list t nil) nil "-c"
  			    (concat gdb-cpp-define-alist-program " "
! 				    gdb-cpp-define-alist-flags)))))
  	(define-list (split-string output "\n" t)) (name))
      (setq gdb-define-alist nil)
      (dolist (define define-list)
--- 435,445 ----
  	 (output
  	  (with-output-to-string
  	    (with-current-buffer standard-output
! 	      (and file (file-exists-p file)
! 	      (call-process shell-file-name file
  			    (list t nil) nil "-c"
  			    (concat gdb-cpp-define-alist-program " "
! 				    gdb-cpp-define-alist-flags))))))
  	(define-list (split-string output "\n" t)) (name))
      (setq gdb-define-alist nil)
      (dolist (define define-list)

RE: wrong-type-argument in gud-tooltip-mode

[Herbert Euler]

> How about the patch below. There seems to be no point in running call-process
> with no input file. I could probably also remove the string-match for
> "\\`\\*.+\\*\\'" in gud-tooltip-mode too, as these buffers have no files
> associated with them anyway.

It works.  However, calling `call-process' with its second argument
(INFILE) set to nil here might not be trivial, since at least gcc
prints something when its input is /dev/null:

$ gcc -E -dM - 
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: wrong-type-argument in gud-tooltip-mode

[Herbert Euler]

Because some browser parses my last message incorrectly, let me put a
space character between "<" and "/dev/null" and send again.

> How about the patch below. There seems to be no point in running call-process
> with no input file. I could probably also remove the string-match for
> "\\`\\*.+\\*\\'" in gud-tooltip-mode too, as these buffers have no files
> associated with them anyway.

It works.  However, calling `call-process' with its second argument
(INFILE) set to nil here might not be trivial, since at least gcc
prints something when its input is /dev/null:

$ gcc -E -dM - < /dev/null
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 2
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 3
#define __DEC64_MAX_EXP__ 384
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __UINTMAX_TYPE__ long long unsigned int
#define __linux 1
#define __DEC32_EPSILON__ 1E-6DF
#define __unix 1
#define __LDBL_MAX_EXP__ 16384
#define __linux__ 1
#define __SCHAR_MAX__ 127
#define __USER_LABEL_PREFIX__
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __DEC64_MIN_EXP__ (-383)
#define __DBL_DIG__ 15
#define __FLT_EPSILON__ 1.19209290e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __DEC32_MAX__ 9.999999E96DF
#define __unix__ 1
#define __DECIMAL_DIG__ 21
#define __gnu_linux__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 4
#define __FLT_HAS_DENORM__ 1
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_HAS_INFINITY__ 1
#define __DEC32_MIN_EXP__ (-95)
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __DEC32_MIN__ 1E-95DF
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DBL_HAS_QUIET_NAN__ 1
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__
#define __DBL_HAS_DENORM__ 1
#define __NO_INLINE__ 1
#define __DEC_EVAL_METHOD__ 2
#define __i386 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.2.3 20071123 (prerelease) (Debian 4.2.2-4)"
#define i386 1
#define __DEC64_EPSILON__ 1E-15DD
#define __DEC128_MIN_EXP__ (-6143)
#define __i486__ 1
#define unix 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __DEC32_DEN__ 0.000001E-95DF
#define __ELF__ 1
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __LDBL_DIG__ 18
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __FLT_HAS_INFINITY__ 1
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __DEC64_MANT_DIG__ 16
#define __DEC32_MAX_EXP__ 96
#define linux 1
#define __DEC128_DEN__ 0.000000000000000000000000000000001E-6143DL
#define __LDBL_MANT_DIG__ 64
#define __WCHAR_TYPE__ int
#define __FLT_DIG__ 6
#define __INT_MAX__ 2147483647
#define __i486 1
#define __FLT_MAX_EXP__ 128
#define __DBL_MANT_DIG__ 53
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ unsigned int
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MAX_10_EXP__ 4932
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __FLT_MAX__ 3.40282347e+38F
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long long int
#define __DEC128_MAX_EXP__ 6144
#define __GNUC_MINOR__ 2
#define __DEC32_MANT_DIG__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-4931)
#define __GNUC_GNU_INLINE__ 1

So I think if we prefer to keep the behavior the same as previous
(although some aspects of the previous behavior seem trivial), we
should use a patch like the following one.

Regards,
Guanpeng Xu



*** gdb-ui.el   9 Jan 2008 01:19:35 -0000       1.7.2.87
--- gdb-ui.el   28 Jan 2008 00:08:03 -0000
*************** (defun gdb-use-separate-io-buffer (arg)
*** 431,442 ****

  (defun gdb-create-define-alist ()
    "Create an alist of #define directives for GUD tooltips."
!   (let* ((file (buffer-file-name))
         (output
          (with-output-to-string
            (with-current-buffer standard-output
!             (call-process shell-file-name
!                           (if (file-exists-p file) file nil)
                            (list t nil) nil "-c"
                            (concat gdb-cpp-define-alist-program " "
                                    gdb-cpp-define-alist-flags)))))
--- 431,442 ----

  (defun gdb-create-define-alist ()
    "Create an alist of #define directives for GUD tooltips."
!   (let* ((file (and (buffer-file-name)
!                     (file-exists-p (buffer-file-name))))
         (output
          (with-output-to-string
            (with-current-buffer standard-output
!             (call-process shell-file-name file
                            (list t nil) nil "-c"
                            (concat gdb-cpp-define-alist-program " "
                                    gdb-cpp-define-alist-flags)))))
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: wrong-type-argument in gud-tooltip-mode

[Nick Roberts]

 > It works.  However, calling `call-process' with its second argument
 > (INFILE) set to nil here might not be trivial, since at least gcc
 > prints something when its input is /dev/null:
 > 
 > $ gcc -E -dM - < /dev/null
 > #define __DBL_MIN_EXP__ (-1021)
 > #define __FLT_MIN__ 1.17549435e-38F
 >...

Yes but we don't need these lists in buffers without associated files.

 > So I think if we prefer to keep the behavior the same as previous
 > (although some aspects of the previous behavior seem trivial), we
 > should use a patch like the following one.

I don't think we need the old behaviour, so I've committed my patch.

Thanks for the report.

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

RE: wrong-type-argument in gud-tooltip-mode

[Herbert Euler]

> I don't think we need the old behaviour, so I've committed my patch.

Thank you :D

Regards,
Guanpeng Xu
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/