emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calling Lisp from undo.c's record_* functions


From: Phillip Lord
Subject: Re: Calling Lisp from undo.c's record_* functions
Date: Tue, 17 Nov 2015 21:13:00 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Phillip Lord)
>> Cc: Eli Zaretskii <address@hidden>,  <address@hidden>
>> Date: Tue, 17 Nov 2015 12:14:27 +0000
>> 
>> I've pushed an unfinished fix to fix/segfault-from-run-undoable-change
>
> Thanks.

That potential fix is finished now. It seems to work (in terms of
functionality) but I can't assess whether it fixes the segfault.

>> I'm pretty sure my implementation in C could be simpler. I wasn't sure
>> how to get from the current-buffer variable in C, to the Lisp_Object
>
> See XSETBUFFER.

Thanks!

>
>> The second part of the plan is to change simple.el to use a idle timer,
>> as I suggested yesterday. I'll do that later today.
>
> What does that timer do?

The timer is an emergency backstop for circumstances when Emacs is
making undoable changes but commands are not happening. Obvious
circumstances for this would be Emacs with a process buffer.


> Would it work to have a non-idle timer that is started once at
> startup, and then never shut down, and have its job be put on some
> list that the timer will examine?

Yes, but it's wasteful.



>> At the moment, I can't replicate the problem, though.
>
> The crash happened for me when the build ran this command in
> admin/grammars/:
>
>   EMACSLOADPATH= "../../src/emacs.exe" -batch --no-site-file --no-site-lisp -l
> semantic/wisent/grammar -f wisent-batch-make-parser -o
> "../../lisp/cedet/semantic/wisent/python-wy.el" python.wy
>
> Try it, maybe it will happen to you as well.  The crash is elusive
> (naturally, since it depends on how much consing was done before
> that).  It happened to me in a 32-bit build with wide ints, but not
> without wide ints.  Also, the build was optimized (-O2), so maybe
> that, too, is a prerequisite for reproducing.

I'm not running on w32, unfortunately. I tried:

EMACSLOADPATH= "../../src/emacs"  -batch --no-site-file --no-site-lisp -l 
semantic/wisent/grammar -f wisent-batch-make-parser -o 
"../../lisp/cedet/semantic/wisent/python-wy.el" python.wy

which works fine.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]