Emacs 22.0.50, AucTeX, and Gnuserv problems

Emacs 22.0.50, AucTeX, and Gnuserv problems

[Robert McDonald]

I am running David Kastrup's 06/24 build of emacs for Windows (including 
AucTeX) and using it with MikTeX 2.4 and 2.5 under XP SP2. For the most 
part it works great -- I can do forward and inverse DVI search with Yap, 
for example --, but every now and then there is a crash when I invoke an 
external program such as LaTeX or BibTeX. Most recently I got an error 
in ntdll.dll (offset 00010f29). After I close the windows error box I 
get a gnuserv error message "Error 109 when reading from stdin! 
Aborting." I am using a February 2005 gnuserv (last modified I believe 
by Lennart Borgman) but I have tried different versions of GnuServ and 
it doesn't seem to matter. I may have configured things wrong, so any 
help or advice would be welcomed. This also may be due to emacs 22 still 
being in beta. The problem does not occur with the same .emacs file 
using 21.3.

Here are two pieces of my .emacs that may be problematic:

(setq TeX-command-list
   (list (list "TeX" "tex \\nonstopmode\\input %t" 'TeX-run-TeX nil t)
	(list "LaTeX" "latex --src-specials=par \nonstopmode\\input{%t}"
		'TeX-run-LaTeX nil t)
	(list "Yap" "yap -1 -s%n%b %d" 'TeX-run-discard nil nil)
	(list "Print" "gsview32 %f" 'TeX-run-command t nil)
	(list "File" "dvips %d -o %f " 'TeX-run-command t nil)
	(list "BibTeX" "bibtex %s" 'TeX-run-BibTeX nil nil)
	(list "Index" "makeindex %s" 'TeX-run-command nil t)
	(list "Check" "lacheck %s" 'TeX-run-compile nil t)
	(list "Other" "" 'TeX-run-command t t)))


(load "~/util/gnuserv.el")
(require 'gnuserv)
(gnuserv-start)
(setq gnuserv-frame (selected-frame))


Any ideas? Thanks in advance.

Bob

reproducing the crash

[Robert McDonald]

Robert McDonald wrote:
<snip>

> every now and then there is a crash when I invoke an 
> external program such as LaTeX or BibTeX. 

I have narrowed down the circumstances in which there is a crash. All of 
the following steps are taken by invoking menu items (from 
setq-command-list). In particular, I am not using the AucTeX C-c C-c. In 
limited testing that does *not* seem to cause the problem below.

1. LaTeX the current file. (Any file seems to work, but a specific 
example is at the end of this message.)

2. Invoke the previewer.

3. Return to emacs and edit the file (for example, insert a space after 
the word "file" in the sample below).

4. LaTeX the file without first saving the file.

5. Respond "yes" when emacs asks whether to save the current file.

6. Invoke the previewer again.

7. If there is no crash, return to step 3 and continue.

This always crashes for me within two or three invocations of Yap.

At one point I got this crash error message:

The instruction at "0x7c910f29" referenced memory at "0x00080191". The 
memory could not be "read". Then I again get the Error 109, etc.

Here is the test latex file:

\documentclass{article}

\begin{document}
Here is a test file

Another line.

\end{document}

Re: reproducing the crash

[Peter Dyballa]

Am 13.09.2006 um 19:26 schrieb Robert McDonald:

> 6. Invoke the previewer again.

What previewer are you invoking again, that cannot re-read  
automatically the changed TeX output file?
How do you do this?

--
Greetings

   Pete

                   Sorry my terrible English, my native language Lisp!

Re: reproducing the crash

[Reiner Steib]

On Wed, Sep 13 2006, Robert McDonald wrote:

> This always crashes for me within two or three invocations of Yap.
>
> At one point I got this crash error message:
>
> The instruction at "0x7c910f29" referenced memory at "0x00080191". The memory
> could not be "read". Then I again get the Error 109, etc.

If Emacs crashed, it's a bug in Emacs because lisp code like AUCTeX
should never crash Emacs.  The best thing would be to build Emacs with
the current sources, run Emacs under a debugger and reproduce the
crash.  If you can't, I suggest to report it using `M-x
report-emacs-bug RET' nevertheless.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: reproducing the crash

[Robert McDonald]

Reiner Steib wrote:
> If Emacs crashed, it's a bug in Emacs because lisp code like AUCTeX
> should never crash Emacs.  The best thing would be to build Emacs with
> the current sources, run Emacs under a debugger and reproduce the
> crash.  If you can't, I suggest to report it using `M-x
> report-emacs-bug RET' nevertheless.

Thank you Reiner. I'm not in a position to build and debug so I will 
wait and see if I can get a little more information from this thread. It 
might narrow down the problem. However, one way or the other I will 
report this to the emacs-dev folks.

Thanks.

Bob

Re: reproducing the crash

[Robert McDonald]

Peter Dyballa wrote:
> 
> Am 13.09.2006 um 19:26 schrieb Robert McDonald:
> 
>> 6. Invoke the previewer again.
> 
> What previewer are you invoking again, that cannot re-read automatically 
> the changed TeX output file?
> How do you do this?


I am using Yap. It does re-read automatically the changed file. You can 
get it to re-read either by switching to the Yap window (alt-Tab), or by 
invoking yap via the menu command, in which case you are returned to the 
previous window. The advantage of using the menu command is that  it 
sets the view location in yap to your current location in the .tex file, 
so that is my habit.

Bob

Re: reproducing the crash

[Peter Dyballa]

Am 13.09.2006 um 20:41 schrieb Robert McDonald:

> The advantage of using the menu command

Does yap return control back to GNU Emacs? I am not using any  
Losedows, I just know that in UNIX an application can be launched  
from GNU Emacs, that never returns control back to it until it is  
killed, the process removed from memory. All this time GNU Emacs  
would be blocked. How is this going on with yap? Is yap sending  
signals to its parent process?

As far as I understand you are using AUCTeX for some things, and you  
have your own "interface" to part of TeX. Can't you integrate your  
"interface" into AUCTeX (via the *Customize* buffer)? Just to see  
whether AUCTeX can handle yap. If this works without crashes, then  
this is an indication that your "interface" has some bug or unwanted  
side-effect.

--
Greetings

   Pete

Bake Pizza not war!

Re: reproducing the crash

[Robert McDonald]

Peter Dyballa wrote:
> 
> Am 13.09.2006 um 20:41 schrieb Robert McDonald:
> 
>> The advantage of using the menu command
> 
> Does yap return control back to GNU Emacs? I am not using any Losedows, 
> I just know that in UNIX an application can be launched from GNU Emacs, 
> that never returns control back to it until it is killed, the process 
> removed from memory. All this time GNU Emacs would be blocked. How is 
> this going on with yap? Is yap sending signals to its parent process?
> 
> As far as I understand you are using AUCTeX for some things, and you 
> have your own "interface" to part of TeX. Can't you integrate your 
> "interface" into AUCTeX (via the *Customize* buffer)? Just to see 
> whether AUCTeX can handle yap. If this works without crashes, then this 
> is an indication that your "interface" has some bug or unwanted 
> side-effect.

I must be making this sound more complicated than it is. I understand 
what you're saying about control, but Yap never takes control away from 
Emacs. There is a single instance of Yap. I can at any time use either 
Yap or emacs. I can double-click in yap and be taken to the 
corresponding spot in the LaTeX source and I can use emacs to 
communicate with Yap and be taken to the corresponding spot in the dvi 
file. This communication occurs via Gnuserv. I am using AucTeX 
exclusively for my emacs interface to all of this. I needed to customize 
the AucTeX menu items to correspond to my dvi viewer, but it is all 
AucTex. I hope this is clearer. Thanks for your interest.

Bob

Re: reproducing the crash

[Ralf Angeli]

* Robert McDonald (2006-09-13) writes:

> I have narrowed down the circumstances in which there is a crash. All of 
> the following steps are taken by invoking menu items (from 
> setq-command-list).

CVS Emacs on Windows is known to crash when menus as constructed by
AUCTeX are involved.  The workaround until this is fixed is not to use
such menus.

-- 
Ralf

Re: reproducing the crash

[David Kastrup]

Ralf Angeli <dev.null@caeruleus.net> writes:

> * Robert McDonald (2006-09-13) writes:
>
>> I have narrowed down the circumstances in which there is a
>> crash. All of the following steps are taken by invoking menu items
>> (from setq-command-list).
>
> CVS Emacs on Windows is known to crash when menus as constructed by
> AUCTeX are involved.

It is?  Why is nothing mentioned in admin/FOR-RELEASE?  What is
special about the AUCTeX menus?

> The workaround until this is fixed is not to use such menus.

Which menus?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: reproducing the crash

[Ralf Angeli]

* David Kastrup (2006-09-14) writes:

> Ralf Angeli <dev.null@caeruleus.net> writes:
>
>> CVS Emacs on Windows is known to crash when menus as constructed by
>> AUCTeX are involved.
>
> It is?  Why is nothing mentioned in admin/FOR-RELEASE?

Possibly because the problem appears only on Windows.

> What is
> special about the AUCTeX menus?
>
>> The workaround until this is fixed is not to use such menus.
>
> Which menus?

A test case can be found in
<URL:http://thread.gmane.org/gmane.emacs.pretest.bugs/13177>.

-- 
Ralf

Re: reproducing the crash

[Robert McDonald]

Ralf Angeli wrote:
> 
> CVS Emacs on Windows is known to crash when menus as constructed by
> AUCTeX are involved.  The workaround until this is fixed is not to use
> such menus.
> 

Thank you! I wish it were not a problem, but I'm very happy to hear that 
    the development folks know about it.

Bob