Discussion:
Weird compilation issue: identical files give different results.
stefano franchi
2014-10-05 15:49:47 UTC
Permalink
As detailed in another thread, I struggled trying to pin down the source of
a weird biblatex related error in a big document I am working on. The doc
itself is composed of a master document and numerous child documents, one
per chapter.

My strategy was to duplicate the master file, then start bisecting until I
narrowed it down to one chapter, then bisect on the chapter until I got it
down to the wrong line, etc. Given that each compilation takes several
minutes, I spent my whole morning doing this. Nonetheless, I eventually
tracked the error down to a typo in a reference. as reported elsewhere.

Once I found the error, I set restoring the original setup. This is where
the weirdness started to happen. I did the following:

1. Fixed the reference
2. Tried to compile the original document
3. Failed with the same error!

This was strange. Perhaps there were two unrelated errors, and my bisecting
had failed? I recreated the error in the ref, repeated, with variations,
the same bisecting steps as above (count another 2 hours), and reached the
same result. No other errors were present. Yet, I repeated steps 1-2 above
and got the same result, compilation still failed. So I tried this:

4. Save the original master doc with a new name (as before)
5. Try to compile the newly created file **without touching it in any way**
6. Compilation succeeds!
7. Try to compile the identical, original master file
8. Compilation fails

Weird. Perhaps LyX caches some intermediate files (bbl and bcf) , I
thought, in its tempdirs (/tmp/lyx... etc).
So I quit lyx, manually erased LyX's directory in /tmp, restarted lyx and
tried again steps 4-8. I got the same results. I even thought saving a file
with a new name would introduce some slight alteration in its content.
Nope. diff confirms the files are byte-identical. Yet one fails and the
other succeeds.

I have no idea what is going on. The only logical answer, in my mind, is
that there are some cached results still lying somewhere. But where?

Cheers,

Stefano
--
__________________________________________________
Stefano Franchi

***@gmail.com <***@tamu.edu>
http://stefano.cleinias.org
Jürgen Spitzmüller
2014-10-05 16:42:40 UTC
Permalink
Post by stefano franchi
I have no idea what is going on. The only logical answer, in my mind, is
that there are some cached results still lying somewhere. But where?
I think biber is also caching things.

Jürgen
stefano franchi
2014-10-05 17:38:46 UTC
Permalink
Post by Jürgen Spitzmüller
Post by stefano franchi
I have no idea what is going on. The only logical answer, in my mind, is
that there are some cached results still lying somewhere. But where?
I think biber is also caching things.
That may be the case, as I have now solved the problem (but not found an
explanation yet).
So it turns out I had a bunch of auxiliary files related to the failing
document in the document's own directory. But none related to its
successful twin. (These files were left over from the command line
compilations). Once I deleted those, compilation finally succeeded.
I wonder why this happened though. Biber may have been responsible, even
though it escapes me why it should read a file in the document's original
directory when it is called on a file in a completely unrelated branch of
the directory tree.

There is a related thread on SX [1] that mentions issues arising with
biber's cache. However, in my case, I didn't touch that cache (I didn't
think of checking biber's behavior before erasing the files in the doc's
own dir, unfortunately).


So the problem is solved, yet the mystery remains.

S.

[1]
http://tex.stackexchange.com/questions/140814/biblatex-biber-fails-with-a-strange-error-about-missing-recode-data-xml-file
--
__________________________________________________
Stefano Franchi

***@gmail.com <***@tamu.edu>
http://stefano.cleinias.org
Julien Rioux
2014-10-05 18:02:53 UTC
Permalink
Post by Jürgen Spitzmüller
Post by stefano franchi
I have no idea what is going on. The only logical answer, in my mind, is
that there are some cached results still lying somewhere. But where?
I think biber is also caching things.
That may be the case, as I have now solved the problem (but not found an
explanation yet).
So it turns out I had a bunch of auxiliary files related to the failing
document in the document's own directory. But none related to its
successful twin. (These files were left over from the command line
compilations). Once I deleted those, compilation finally succeeded.
I think the explanation is that you suffered from this issue:
http://www.lyx.org/trac/ticket/8000

Cheers,
Julien
stefano franchi
2014-10-06 12:33:57 UTC
Permalink
Post by Julien Rioux
Post by stefano franchi
Post by stefano franchi
I have no idea what is going on. The only logical answer, in my
mind, is
Post by stefano franchi
that there are some cached results still lying somewhere. But where?
I think biber is also caching things.
That may be the case, as I have now solved the problem (but not found an
explanation yet).
So it turns out I had a bunch of auxiliary files related to the failing
document in the document's own directory. But none related to its
successful twin. (These files were left over from the command line
compilations). Once I deleted those, compilation finally succeeded.
http://www.lyx.org/trac/ticket/8000
Thanks Julien,

that sounds exactly right. I was not aware of this LaTeX behavior
(TEXINPUTS, etc). It would indeed be great if LyX could produce a warning
when it finds itself in such a situation (old bbl file in doc's dir). It
would have certainly saved me a few hours of work.

Cheers,

Stefano
--
__________________________________________________
Stefano Franchi

***@gmail.com <***@tamu.edu>
http://stefano.cleinias.org
Loading...