GNU bug report logs - #6835
23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal error (11) Segmentation fault

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6835 in the body.
You can then email your comments to 6835 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal error (11) 
	Segmentation fault
Date: Mon, 9 Aug 2010 21:04:50 -0400

eval'ing `type-of' with #[abc] gets me Fatal error (11) Segmentation fault

emacs -Q

To reproduce enter:
(type-of  #[abc])

type C-x C-e `eval-last-sexp'

Get hosed with:
=> Fatal error (11)Segmentation fault

"GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-05-10"

--
/s_P\

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a
	Fatal error (11) Segmentation fault
Date: Mon, 09 Aug 2010 21:23:37 -0600

MON KEY wrote:
> eval'ing `type-of' with #[abc] gets me Fatal error (11) Segmentation fault
> 
> emacs -Q
> 
> To reproduce enter:
> (type-of  #[abc])
> 
> type C-x C-e `eval-last-sexp'
> 
> Get hosed with:
> => Fatal error (11)Segmentation fault
> 
> "GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.20.0)
>  of 2010-05-10"

GNU Emacs 23.2.1 (i386-apple-darwin8.11.1, NS apple-appkit-824.48) of 2010-05-14

and

GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08

don't crash, but they both produce these results:

(type-of #[abc])
⇒ compiled-function

(functionp #[abc])
⇒ t

(funcall #[abc])
⇒ Debugger entered--Lisp error: (invalid-function #[abc])

Shouldn't anything that satisfies functionp be a valid argument to funcall?

Shouldn't the COMPILEDP macro in lisp.h be more strict about the number and type
of vector elements?  The "Byte-Code Function Objects" node of the Elisp manual
says:

   A byte-code function object must have at least four elements; there
is no maximum number, but only the first six elements have any normal
use.  They are:

ARGLIST
     The list of argument symbols.

BYTE-CODE
     The string containing the byte-code instructions.

CONSTANTS
     The vector of Lisp objects referenced by the byte code.  These
     include symbols used as function names and variable names.

STACKSIZE
     The maximum stack size this function needs.

DOCSTRING
     The documentation string (if any); otherwise, `nil'.  The value may
     be a number or a list, in case the documentation string is stored
     in a file.  Use the function `documentation' to get the real
     documentation string (*note Accessing Documentation::).

INTERACTIVE
     The interactive spec (if any).  This can be a string or a Lisp
     expression.  It is `nil' for a function that isn't interactive.


-- 
Kevin Rodgers
Denver, Colorado, USA

Message #11 received at 6835 <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: 6835 <at> debbugs.gnu.org
Cc: kevin.d.rodgers <at> gmail.com
Subject: bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a Fatal 
	error (11) Segmentation fault
Date: Tue, 10 Aug 2010 02:47:39 -0400

> GNU Emacs 23.2.1 (i386-apple-darwin8.11.1, NS apple-appkit-824.48) of
> 2010-05-14
> and
> GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) of 2010-05-08
> don't crash, but they both produce these results:

I'm able to reproduce this w/ 23.2 on a second machine:

"GNU Emacs 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.14.7)
 of 2010-05-10"

> Shouldn't anything that satisfies functionp be a valid argument to
> funcall?

I think it is the wrong question.

Why can't/shouldn't the `#' read restrictions be made less
"complicated"?

> Shouldn't the COMPILEDP macro in lisp.h be more strict about the
> number and type of vector elements?  The "Byte-Code Function
> Objects" node of the Elisp manual says:

Yes well, this may bring us circuitously semi-circle to bug#6486
(URL `http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-06/msg00486.html')

Abstractly, I just don't understand the rationale for the nuanced
restrictions placed on the reader w/re `#'. It seems to cause just as
many "complicated problems" as presumably it was intended to solve.

Moreover, we now have a new hash-table read-syntax so... WTF?

,---- (info "(elisp)Creating Hash")
|    You can also create a new hash table using the printed
| representation for hash tables.  The Lisp reader can read this
| printed representation, provided each element in the specified hash
| table has a valid read syntax (see Printed Representation).  For
| instance, the following specifies a new hash table containing the
| keys `key1' and `key2' (both symbols) associated with `val1' (a
| symbol) and `300' (a number) respectively.
|
|      #s(hash-table size 30 data (key1 val1 key2 300))
`----

(setq bubbas-hash #s(hash-table size 30 data (key1 val1 key2 300)))
;=> #s(hash-table {...} ))

bubbas-hash
;=> #s(hash-table {...} ))

(gethash 'key1 bubbas-hash)
;=> val1

(type-of (symbol-value 'bubbas-hash))
;=> hash-table

IOW, I can successfully interrogate a hash-table type and this
pathological corner-case too:

(type-of #'(lambda))
;=> cons

but woe be it to she who slips up and does:

(type-of #[say goodbye to your current-session ... now])

Which reminds me, how are the the Guile folks planning on handling
this with Guile-Elisp?

There may be some _nasty_ bugs/headaches working around the current
elisp reader restrictions e.g. #t and #f and more specifically
#:keywords.

Following from a fairly recent draft of the Guile manual:

,----
| (read-set! keywords 'prefix)
|
| #:type
| ;=> #:type
|
| :type
| ;=> #:type
|
| (read-set! keywords 'postfix)
| type:
| ;=> #:type
|
| :type
| ;=> :type
|
| (read-set! keywords #f)
| #:type
| ;=> #:type
`----

Did you catch that last one?
We eval #f -- the Scheme equivalent of nil and/or '(); and we get a
potentially bogus error prone elisp on return.

Whoopee. Looks likes someone's syntactic jujitsu (most likely born of
political infighting and vengeful bone to pick) might wind up biting
back 20+ years later.

> Kevin Rodgers

--
/s_P\

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6835: 23.2;
	eval'ing `type-of' with #[abc] as arg gets a Fatal error (11)
	Segmentation fault
Date: Tue, 10 Aug 2010 10:27:19 +0200

> (functionp #[abc])
> ⇒ t

> (funcall #[abc])
> ⇒ Debugger entered--Lisp error: (invalid-function #[abc])

> Shouldn't anything that satisfies functionp be a valid argument to funcall?

Yes and no.  Should (lambda 3) be accepted by functionp?  What about
(lambda () . 3) ?  What about (lambda () (+ . 1)) and other errors?

#[abc] is an object of "function type", which is why functionp
returns t.  I don't think that it's terribly important if when calling
it, you get an error, since that can happen for syntactically valid
functions as well.


        Stefan

Message #19 received at 6835-done <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 6835-done <at> debbugs.gnu.org
Subject: Re: bug#6835: 23.2;
	eval'ing `type-of' with #[abc] as arg gets a Fatal error (11)
	Segmentation fault
Date: Tue, 10 Aug 2010 23:14:42 +0200

MON KEY <monkey <at> sandpframing.com> writes:

> eval'ing `type-of' with #[abc] gets me Fatal error (11) Segmentation fault

This is already fixed (and has nothing to do with type-of).

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a
	Fatal error (11) Segmentation fault
Date: Tue, 10 Aug 2010 23:42:20 -0600

Stefan Monnier wrote:
>> (functionp #[abc])
>> ⇒ t
> 
>> (funcall #[abc])
>> ⇒ Debugger entered--Lisp error: (invalid-function #[abc])
> 
>> Shouldn't anything that satisfies functionp be a valid argument to funcall?
> 
> Yes and no.  Should (lambda 3) be accepted by functionp?  What about
> (lambda () . 3) ?  What about (lambda () (+ . 1)) and other errors?

Hi Stefan,

I don't see why those examples should satisfy functionp.  The Elisp manual says:

 -- Function: functionp object
     This function returns `t' if OBJECT is any kind of function, i.e.
     can be passed to `funcall'.  Note that `functionp' returns `nil'
     for special forms (*note Special Forms::).

I think your examples are merely cons objects that look like lambda expressions
(a function subtype) but are not.

Note that type-of returns cons for both valid lambda expressions and those
examples, i.e. it does not distinguish special list structures as separate
types (e.g. alists, lambda expressions).  Likewise, type-of does not distinguish
obarrays from non-obarray vectors.

I think type-of should either return the most specific type that the object
satisfies or the most general type, but not the most specific for some things
(e.g. functions) and the most general for others (e.g. lists, vectors).

> #[abc] is an object of "function type", which is why functionp
> returns t.  I don't think that it's terribly important if when calling
> it, you get an error, since that can happen for syntactically valid
> functions as well.

But it is useful to know whether the error is signaled by funcall or
by the function.  And a careful programmer ought to be able to avoid
the former by guarding the funcall form with functionp.

-- 
Kevin Rodgers
Denver, Colorado, USA

Message #25 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6835: 23.2;
	eval'ing `type-of' with #[abc] as arg gets a Fatal error (11)
	Segmentation fault
Date: Wed, 11 Aug 2010 22:20:24 +0200

>> Yes and no.  Should (lambda 3) be accepted by functionp?  What about
>> (lambda () . 3) ?  What about (lambda () (+ . 1)) and other errors?

> I don't see why those examples should satisfy functionp.  The Elisp
> manual says:

Because (lambda () 1) is a valid function that can be passed to
`funcall'.

> I think your examples are merely cons objects that look like lambda
> expressions (a function subtype) but are not.

They're both cons objects and functions.

> But it is useful to know whether the error is signaled by funcall or
> by the function.

Why?


        Stefan

Message #28 received at 6835 <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 6835 <at> debbugs.gnu.org
Subject: Re: bug#6835: 23.2; eval'ing `type-of' with #[abc] as arg gets a 
	Fatal error (11) Segmentation fault
Date: Wed, 11 Aug 2010 20:12:48 -0400

On Tue, Aug 10, 2010 at 5:14 PM, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> MON KEY <monkey <at> sandpframing.com> writes:
>
>> eval'ing `type-of' with #[abc] gets me Fatal error (11) Segmentation fault
>
> This is already fixed (and has nothing to do with type-of).

Why was this bug closed?

Can you confirm you were able to reproduce the bug I reported?

If it is indeed fixed would you please indicate (at least _something_)
w/re to what the nature of the problem was/is and what was needed to
fix it.

This one caught me with a six day old Emacs session when it went down.
It would be nice to know more about the nature of the thing that left
me in a lurch.

Your pithy dismissals that :

"(and has nothing to do with type-of)."

undermine (my) confidence that it has indeed been fixed esp. as
`type-of' does consistently bring down my Emacs. If the problem is/was
elsewhere I would like to know more about how you were able to make
this determiation.

FWIW I'm happy to continue finding corner cases related to this one
and filing subsequent new reports in the absence of some explanation
slightly more verbose than the presently one provided.

> Andreas.

--
/s_P\

Message #31 received at 6835 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: MON KEY <monkey <at> sandpframing.com>
Cc: 6835 <at> debbugs.gnu.org
Subject: Re: bug#6835: 23.2;
	eval'ing `type-of' with #[abc] as arg gets a Fatal error (11)
	Segmentation fault
Date: Thu, 12 Aug 2010 09:56:02 +0200

MON KEY <monkey <at> sandpframing.com> writes:

> Why was this bug closed?

Because it is fixed.

> what was needed to fix it.

See make-byte-code.

> `type-of' does consistently bring down my Emacs.

Try without type-of.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #34 received at 6835 <at> debbugs.gnu.org (full text, mbox):

From: MON KEY <monkey <at> sandpframing.com>
To: 6855 <at> debbugs.gnu.org
Cc: 6835 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: bug#6855: 24.0.50; Bug in tool bar label handling
Date: Sun, 15 Aug 2010 19:45:31 -0400

> I don't agree.  Emacs should be robust against type mismatches,
> crashing is the worst possible reaction.

Unless of course that robustness is requested of `type-of', in which
case presumably Andreas waffles and TRT is to simply not use a type
macthing feature that may cause Emacs to crash, e.g. this recent
comment re bug#6835:

,----
|
| > `type-of' does consistently bring down my Emacs.
|
| Try without type-of.
|
| Andreas.
|
`---- http://lists.gnu.org/archive/html/bug-gnu-emacs/2010-08/msg00337.html

:-P

> Andreas.

--
/s_P\

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.