[XeTeX] Low-level diagnostic ("fwrite") generated by XeTeX

[Jonathan Kew]

I think the scenario here is pretty clear. You'd get the same "fwrite" error message from (the web2c implementation of) TeX itself if it were to run out of disk space while writing the dvi output, or if the dvi file were to become unwritable for some other reason in the midst of the run. But that's a fairly unlikely situation. (If the intended dvi file can't be opened for writing in the first place, you get a properly-handled error.)

With xetex, however, because its default behavior is to pipe output to an xdv-to-pdf driver, things are a little more complex. The xetex process itself does not detect the unwritable output directly when trying to open a file; the open command for xetex's output file (or rather pipe) succeeds, because this does not depend on being able to write to the pdf file, only on being able to start the driver process. So as far as xetex itself is concerned, it has successfully opened the output stream. Then it starts writing output.

At some point (asynchronously), the output driver is ready to begin writing *it's* output (the pdf). That's when the problem is detected, because Acrobat has the file locked. So the driver aborts with a message to stderr ("** ERROR ** Unable to open...."), and terminates. This means xetex no longer has a valid destination (pipe) for its xdv output; the process on the other end of the pipe is gone. So the next time it has a buffer of xdv data ready, and calls fwrite, that fails, and the web2c code (see the WRITE_OUT macro in texmfmp.h) treats this as a fatal error and abruptly terminates xetex.

Possible solutions: (a) make the WRITE_OUT macro do something friendlier than just calling FATAL_PERROR("fwrite") in the case of an error; or (b) have xetex check that the intended pdf destination is writable as part of its open_dvi_output function, before actually opening the pipe.

Option (b) is likely to be simpler, and more parallel to the existing behavior of TeX, though it is not 100% robust - but probably good enough.

JK

On 3 Feb 2010, at 07:08, Keith J. Schultz wrote:

> Hi Everybody,
> 
> 	As Jonathan said there has to be some better
> 	error handling here. 
> 	The questions are:
> 		1) what is returned by the different processes
> 		2) should something different be returned
> 		3) is a processs not checking the exit code?
> 
> 	From what a have read it seems that XeTex already has
> 	a file handle and tries to send data to it, but gets told it can not!
> 	So how did XeTex get this handle in the first place or did it
> 	become invalid after being passed on?
> 
> 	For me it is a bug, because the handle should be check once it comes
> 	back or when it was created.
> 
> 	regards
> 		Keith.
> 
> Am 02.02.2010 um 19:59 schrieb Philip TAYLOR:
> 
>> 
>> 
>> Khaled Hosny wrote:
>> 
>>> Since, AFAIK, Adobe Reader doesn't change files (it is a reader not
>>> writer), it shouldn't lock the file in the first place. This what other
>>> document viewers (Evince here) does, actually it also recognize that the
>>> file has been updated and reload it.
>> 
>> Although I have some understandable sympathy with this perspective,
>> I should just clarify that the file was open in <stress>Adobe
>> Acrobat</>, not Acrobat Reader, so it is quite understandable
>> that the former should lock the file as it is potentially
>> modifiable by the application.  But as I said in my earlier
>> response to Ross, I don't think this is the issue : XeTeX,
>> as Jonathan had already agreed, should be more robust when
>> encountering such an error and not fall back on a low-level
>> diagnostic.
>> 
>> ** Phil.
>> 
>> 
>> --------------------------------------------------
>> Subscriptions, Archive, and List information, etc.:
>> http://tug.org/mailman/listinfo/xetex
> 
> 
> 
> --------------------------------------------------
> Subscriptions, Archive, and List information, etc.:
>  http://tug.org/mailman/listinfo/xetex