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

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

[MON KEY]

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\

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

[Kevin Rodgers]

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

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

[Stefan Monnier]

> (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

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

[Kevin Rodgers]

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

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

[Stefan Monnier]

>> 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

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

[MON KEY]

> 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\

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

[Andreas Schwab]

MON KEY <monkey@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[MON KEY]

On Tue, Aug 10, 2010 at 5:14 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> MON KEY <monkey@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\

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

[Andreas Schwab]

MON KEY <monkey@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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#6835: bug#6855: 24.0.50; Bug in tool bar label handling

[MON KEY]

> 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\