GNU bug report logs - #11105
24.0.94; (wrong-type-argument strinp (eval.c))

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 11105 in the body.
You can then email your comments to 11105 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: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.94; (wrong-type-argument strinp (eval.c))
Date: Tue, 27 Mar 2012 16:41:47 -0700

I get this error message from time to time - have to go to *Messages* to
find it, so something must be preventing it from surfacing:
 
Error in post-command-hook (#[nil \300\301!\207 [run-hooks
icomplete-post-command-hook] 2]): (wrong-type-argument stringp (eval.c))
 
Sorry, but I have no more info than that.  I tried looking at
`icomplete-exhibit', which is the only function on
`icomplete-post-command-hook', to see if I could guess what the problem
is, but I didn't succeed.  Feel free to close this, if it doesn't help
you find a problem.

In GNU Emacs 24.0.94.1 (i386-mingw-nt5.1.2600)
 of 2012-03-19 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11105 <at> debbugs.gnu.org
Subject: Re: bug#11105: 24.0.94; (wrong-type-argument strinp (eval.c))
Date: Wed, 28 Mar 2012 12:00:46 -0400

> I get this error message from time to time - have to go to *Messages* to
> find it, so something must be preventing it from surfacing:
 
> Error in post-command-hook (#[nil \300\301!\207 [run-hooks
> icomplete-post-command-hook] 2]): (wrong-type-argument stringp (eval.c))
 
> Sorry, but I have no more info than that.  I tried looking at
> `icomplete-exhibit', which is the only function on
> `icomplete-post-command-hook', to see if I could guess what the problem
> is, but I didn't succeed.  Feel free to close this, if it doesn't help
> you find a problem.

If you can figure out how to trigger it, or at least describe the
circumstance where it happens, maybe we can track it down, but without
that info it doesn't seem easy to figure out what's going on.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 11105 <at> debbugs.gnu.org
Subject: RE: bug#11105: 24.0.94; (wrong-type-argument strinp (eval.c))
Date: Wed, 28 Mar 2012 09:07:05 -0700

> If you can figure out how to trigger it, or at least describe the
> circumstance where it happens, maybe we can track it down, but without
> that info it doesn't seem easy to figure out what's going on.

Yes, I know.  This has been happening for a while (in Emacs 24), and I've tried
to find out what leads to it, but no success so far.  I was hoping that perhaps
someone would notice something in the code that might be suspect.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 11105 <at> debbugs.gnu.org
Subject: Re: bug#11105: 24.0.94; (wrong-type-argument strinp (eval.c))
Date: Wed, 28 Mar 2012 14:54:46 -0400

>> If you can figure out how to trigger it, or at least describe the
>> circumstance where it happens, maybe we can track it down, but without
>> that info it doesn't seem easy to figure out what's going on.

> Yes, I know.  This has been happening for a while (in Emacs 24), and
> I've tried to find out what leads to it, but no success so far.  I was
> hoping that perhaps someone would notice something in the code that
> might be suspect.

My crystal ball told me it could be a mis-applied completion predicate
(depending on the kind of completion-table (list of strings, alist,
obarray, hashtable), the predicate is either passed a string,
a cons-cell, or even two arguments), but I didn't notice any obvious
risky uses of the predicate in icomplete, so the problem might be
elsewhere (and just happens to show up in icomplete because icomplete
calls completion more often).


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 11105 <at> debbugs.gnu.org
Subject: RE: bug#11105: 24.0.94; (wrong-type-argument strinp (eval.c))
Date: Wed, 28 Mar 2012 14:11:14 -0700

> My crystal ball told me it could be a mis-applied completion predicate
> (depending on the kind of completion-table (list of strings, alist,
> obarray, hashtable), the predicate is either passed a string,
> a cons-cell, or even two arguments), but I didn't notice any obvious
> risky uses of the predicate in icomplete, so the problem might be
> elsewhere (and just happens to show up in icomplete because icomplete
> calls completion more often).

My thinking too.  Anyway, I'll keep an eye out.

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <11105 <at> debbugs.gnu.org>
Cc: 'Stefan Monnier' <monnier <at> iro.umontreal.ca>
Subject: RE: bug#11105: 24.0.94; (wrong-type-argument strinp (eval.c))
Date: Tue, 2 Oct 2012 16:04:20 -0700

d> I get this error message from time to time - have to go to 
d> *Messages* to find it, so something must be preventing it
d> from surfacing:
d>  
d> Error in post-command-hook (#[nil \300\301!\207 [run-hooks
d> icomplete-post-command-hook] 2]): (wrong-type-argument 
d> stringp (eval.c))
d>  
d> Sorry, but I have no more info than that.  I tried looking at
d> `icomplete-exhibit', which is the only function on
d> `icomplete-post-command-hook', to see if I could guess what 
d> the problem is, but I didn't succeed.  Feel free to close this,
d> if it doesn't help you find a problem.

sm> My crystal ball told me it could be a mis-applied completion
sm> predicate (depending on the kind of completion-table (list of
sm> strings, alist, obarray, hashtable), the predicate is either
sm> passed a string, a cons-cell, or even two arguments), but I
sm> didn't notice any obvious risky uses of the predicate in
sm> icomplete, so the problem might be elsewhere (and just happens
sm> to show up in icomplete because icomplete calls completion more
sm> often).

How right you were, Stefan.

I finally located the problem, which was in my code.

What the problem was, FYI:

I have a modified version of icomplete-completions, which does not use
`completion--field-metadata', `completion-all-sorted-completions', LAST, or
BASE-SIZE.

The second `if' clause, which calls `completion-try-completions', raised an
error when its COMPS arg was a function (not sure why), so I changed the code to
use `try-completion' instead.

The bug was not here, but this is why I was seeing the problem from icomplete:
because icomplete was the only function that actually used `try-completion' with
the code that was bugged.

That other, bugged code was calling `completing-read' with a function-valued
COLLECTION arg, and the final act of that function called `try-completion' on a
string, a collection of singleton string lists, and the original predicate arg.
The predicate here should however expect a singleton list as arg, not a string.
The fix was to change the predicate.

That code never used the `try-completion' case (COMPLETION-MODE = nil), so I
never saw the bug except from icomplete (which in my version calls
`try-completion').

I will close this bug.

Previous Next

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