bug#13007: 24.3.50; emacs_backtrace.txt

["Drew Adams" <drew.adams@oracle.com>]

> > No, I'm sorry Eli, I just don't have the time for that now. 
> > I have reverted to using the Emacs binary before these
> > crashes were introduced.
> 
> Don't you still have the buggy binary on your disk somewhere?

Yes, I do.

> > If you happen to make some progress then I will be glad to 
> > try the result and let you know the effect in my context.
> 
> We cannot make progress, because we cannot reproduce your way to
> trigger the bug.

Then we'll just have to wait until you obtain a recipe from someone else for a
different way to trigger "the bug" or perhaps a related bug.

> > My guess (& hope) is that there is a good chance that 
> > Juanma and I were bitten by the same bug.
> 
> It's the same bug, in the sense that the same assertion is violated.
> But they are 2 different ways of triggering that violation, because
> the call to the faulty function comes from 2 different places (as
> evidenced by the backtrace) and the buffer that is not the current one
> is different in these two cases (*scratch* for Juanma, minibuffer for
> you).

Don't you think that by understanding Juanma's case you will understand ways, in
general, that the assertion can be violated?

If we have already seen more than one way, as you say, that seems like a good
hint that the assertion itself might be flawed: the wrong assertion.  It
suggests to me that the assertion does not understand what it should be
expecting, and it has too narrow a view of things.

IOW, I would expect Juanma's case to turn on some light wrt how the assertion is
wrong.  That's because I'm guessing that the code (apparently more than one code
path) that violates the assertion is not the problem, and the assertion itself
is the problem: the wrong assertion.

(Just a hunch, from ignorance.)
 
> > If not, we can look into my case more later, when I have some more
> > time.
> 
> Please do, and thanks.

Thank you for trying to find a solution.