bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

[Eli Zaretskii <eliz@gnu.org>]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <1077@debbugs.gnu.org>
> Date: Sat, 27 Nov 2010 08:15:17 -0800
> 
> > Please post a complete recipe, starting with "emacs -Q", to reproduce
> > this problem.  Since you are unable to run Emacs under GDB and provide
> > a traceback which would pinpoint the locus of the error, someone else
> > will have to do that, and they will need this recipe.  The details you
> > posted are important, but they will only help once the exact place
> > which throws the error is identified.
> 
> Please read the thread.

I did.  But I can always hope, can't I?

> I don't have a complete recipe starting with emacs -Q.  I've spent hours trying
> to track down this bug.  Believe me, if I had a simple -Q recipe I would have
> sent it long ago.  And that would have saved me lots of time spent in the
> debugger and staring at C-code diffs looking for clues.

Can you install GDB (from the MinGW site) and run Emacs under it?  If
you can install GDB, I can send instructions for how to attach it to
Emacs and set a breakpoint where we want it.  When the breakpoint
breaks, I can tell how to provide the information needed for
identifying the code which barfs.

My only other idea is to define a Lisp function `error' (which will
override the primitive) with the same signature as the primitive,
edebug-defun it, and hope that when the problem happens again, you
will be able to see from the Lisp backtrace who throws the error.

If none of the above helps, then I'm afraid the only chance to fix
this is if someone who can stumbles across the same bug.  That's
because from your descriptions it's quite clear that you have a very
complex non-default setup of how buffers are displayed in frames,
which makes the chances to reproduce this without a recipe slim at
best.

> > > No one has tried to look into this.
> > That's not true.
> 
> Please read the thread.
> 
> Do you see _any_ indication there that anyone has tried to look at the C code of
> the function in question, and at its changes during the time period in question?
> From the beginning I pointed to that code, but I am the only one in thread to
> speak about it.

The fact that you are the only one to post there does not mean no one
else tried to figure it out.  It just means no one had anything
intelligent to say about it.