Pdflatex crashes on command line with university pdf logo

[Claudius Marpa Heine]

Hi LyX developers,

I have a bug when I try to use LyX in a command line to create a pdf
using pdflatex, but when I use LyX over the UI it works.

Here is the command I use:
$ lyx -e pdf2 -f all test.lyx

Here is the simplest LyX file, where the bug occures:
https://dl.dropboxusercontent.com/u/1512554/lyxbug.7z

I tried it with LyX 2.1.0 and 2.2.0dev (2014-04-14)
and pdfTeX 3.1415926-2.5-1.40.14 on Archlinux

On the developer build of LyX the output is:

Looking for python v2.x ...
Examining /usr/bin/python
Examining /usr/bin/python-config
Examining /usr/bin/python2
Found Python 2.7.7

This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Arch Linux)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2011/06/27>
Babel <3.9h> and hyphenation patterns for 78 languages loaded.

Systemcall.cpp (288): Systemcall: 'pdflatex "test.tex"' finished with
exit code 1


Thanks for your time, and great work you have done on LyX!
Claudius

[stefano franchi]

On Tue, Jun 10, 2014 at 12:07 PM, Claudius Marpa Heine <

Post by Claudius Marpa Heine
Hi LyX developers,
I have a bug when I try to use LyX in a command line to create a pdf
using pdflatex, but when I use LyX over the UI it works.
$ lyx -e pdf2 -f all test.lyx
https://dl.dropboxusercontent.com/u/1512554/lyxbug.7z
I tried it with LyX 2.1.0 and 2.2.0dev (2014-04-14)
and pdfTeX 3.1415926-2.5-1.40.14 on Archlinux
Looking for python v2.x ...
Examining /usr/bin/python
Examining /usr/bin/python-config
Examining /usr/bin/python2
Found Python 2.7.7
This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Arch Linux)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2011/06/27>
Babel <3.9h> and hyphenation patterns for 78 languages loaded.
Systemcall.cpp (288): Systemcall: 'pdflatex "test.tex"' finished with
exit code 1

Have you tried getting rid of the umlaut in the logo's filename (and in the
related inset in lyx)?
It worked fine here once I did that, with lyx 2.11dev

Cheers,

Stefano
--
__________________________________________________
Stefano Franchi
Associate Research Professor
Department of Hispanic Studies Ph: [phone]
Texas A&M University Fax: [phone]
College Station, Texas, USA

***@tamu.edu
http://stefano.cleinias.org

[Claudius Marpa Heine]

Hi

Post by stefano franchi
Have you tried getting rid of the umlaut in the logo's filename (and
in the related inset in lyx)?

Thanks, that did it.

So is it a bug that it works in the UI and not in the terminal?
Shouldn't it support unicode paths in both cases?
I thought it worked on a previous version.

Cheers,
Claudius

[Richard Heck]

Post by Claudius Marpa Heine
Hi

Post by stefano franchi
Have you tried getting rid of the umlaut in the logo's filename (and
in the related inset in lyx)?

Thanks, that did it.
So is it a bug that it works in the UI and not in the terminal?
Shouldn't it support unicode paths in both cases?
I thought it worked on a previous version.

Please do report this as a bug on trac.

Richard

[Claudius Marpa Heine]

Hi,

Post by Richard Heck
Please do report this as a bug on trac.

I don't want to create a trac account just to report this single and
rather minor bug. If you would have wanted everyone to report bugs
there, you would allow it without account and then I wouldn't have used
this mailing list to report it in the first place.

Cheers,
Claudius

[Richard Heck]

Post by Claudius Marpa Heine
Hi,

Post by Richard Heck
Please do report this as a bug on trac.

I don't want to create a trac account just to report this single and
rather minor bug. If you would have wanted everyone to report bugs
there, you would allow it without account and then I wouldn't have used
this mailing list to report it in the first place.

I wouldn't call a crash "minor", but never mind: It's been fixed by Enrico.

Richard

[Enrico Forestieri]

Post by Claudius Marpa Heine
Hi

Post by stefano franchi
Have you tried getting rid of the umlaut in the logo's filename (and
in the related inset in lyx)?

Thanks, that did it.
So is it a bug that it works in the UI and not in the terminal?
Shouldn't it support unicode paths in both cases?
I thought it worked on a previous version.

Yes, it works with LyX 2.0. Seemingly, the locale is not correctly set
in LyX 2.1 and 2.2 when the GUI is not used. Indeed, using the attached
patch, when launching LyX normally (such that the GUI appears), I get
the following output:

charset: ANSI_X3.4-1968
charset: ANSI_X3.4-1968
charset: UTF-8
charset: UTF-8
charset: UTF-8

Instead, when executing a batch command, I see:

charset: ANSI_X3.4-1968
charset: ANSI_X3.4-1968
charset: ANSI_X3.4-1968

and then it fails if file names contain non-ascii characters.

However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
batch command succeeds, even if the above output is unchanged.
Go figure...

[Enrico Forestieri]

Post by Enrico Forestieri
However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
batch command succeeds, even if the above output is unchanged.
Go figure...

Anyway, the attached patch fixes the issue for me, using either Qt4 or Qt5.

[Richard Heck]

Post by Enrico Forestieri

Post by Enrico Forestieri
However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
batch command succeeds, even if the above output is unchanged.
Go figure...

Anyway, the attached patch fixes the issue for me, using either Qt4 or Qt5.

Looks good to me. And for 2.1.x.

rh

[Enrico Forestieri]

Post by Richard Heck

Post by Enrico Forestieri

Post by Enrico Forestieri
However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
batch command succeeds, even if the above output is unchanged.
Go figure...

Anyway, the attached patch fixes the issue for me, using either Qt4 or Qt5.

Looks good to me. And for 2.1.x.

I am not convinced that this is the right fix. I think the way we
set the locale is flawed. When a program starts, its default locale
is "C" and the environment's locale settings should be selected by
calling setlocale(LC_ALL,"").

Now, if I place the following line

lyxerr << "Locale is: " << setlocale(LC_ALL, 0) << endl;

at the end of setLocale() in GuiApplication.cpp and launch lyx, I see:

Locale is: C
Locale is: C
Locale is: LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=it_IT.UTF-8;LC_ADDRESS=it_IT.UTF-8;LC_TELEPHONE=it_IT.UTF-8;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=it_IT.UTF-8
Locale is: LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=it_IT.UTF-8;LC_ADDRESS=it_IT.UTF-8;LC_TELEPHONE=it_IT.UTF-8;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=it_IT.UTF-8
Locale is: LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=it_IT.UTF-8;LC_ADDRESS=it_IT.UTF-8;LC_TELEPHONE=it_IT.UTF-8;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=it_IT.UTF-8

meaning that we rely upon something that indirectly sets the locale for us.
I think that the right fix is the attached one. After applying it,
QLocale::system() returns the right thing from the beginning.

[Richard Heck]

Post by Enrico Forestieri

Post by Richard Heck

Post by Enrico Forestieri

Post by Enrico Forestieri
However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
batch command succeeds, even if the above output is unchanged.
Go figure...

Anyway, the attached patch fixes the issue for me, using either Qt4 or Qt5.

Looks good to me. And for 2.1.x.

I am not convinced that this is the right fix. I think the way we
set the locale is flawed. When a program starts, its default locale
is "C" and the environment's locale settings should be selected by
calling setlocale(LC_ALL,"").
Now, if I place the following line
lyxerr << "Locale is: " << setlocale(LC_ALL, 0) << endl;
Locale is: C
Locale is: C
Locale is: LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=it_IT.UTF-8;LC_ADDRESS=it_IT.UTF-8;LC_TELEPHONE=it_IT.UTF-8;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=it_IT.UTF-8
Locale is: LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=it_IT.UTF-8;LC_ADDRESS=it_IT.UTF-8;LC_TELEPHONE=it_IT.UTF-8;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=it_IT.UTF-8
Locale is: LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=it_IT.UTF-8;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=it_IT.UTF-8;LC_ADDRESS=it_IT.UTF-8;LC_TELEPHONE=it_IT.UTF-8;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=it_IT.UTF-8
meaning that we rely upon something that indirectly sets the locale for us.
I think that the right fix is the attached one. After applying it,
QLocale::system() returns the right thing from the beginning.

To be honest, I am not terribly well informed about this sort of topic,
so I am more than happy to take your word for what is right here.

Richard

[Enrico Forestieri]

Post by Richard Heck

Post by Enrico Forestieri
meaning that we rely upon something that indirectly sets the locale for us.
I think that the right fix is the attached one. After applying it,
QLocale::system() returns the right thing from the beginning.

To be honest, I am not terribly well informed about this sort of
topic, so I am more than happy to take your word for what is right
here.

I have checked that it is Qt itself that calls setlocale(LC_ALL, "")
during QCoreApplication initialization. Of course, that is never
performed for batch processing and this explains the bug.

I have also verified that it is not necessary to call setlocale()
on Windows (and in the Qt sources the call is #ifdef'd out by the
guard Q_OS_UNIX), so a better place for the call is os::init().

I am going to commit a patch to both master and stable.

[Jean-Marc Lasgouttes]

Post by Enrico Forestieri

Post by Richard Heck
To be honest, I am not terribly well informed about this sort of
topic, so I am more than happy to take your word for what is right
here.

I have checked that it is Qt itself that calls setlocale(LC_ALL, "")
during QCoreApplication initialization. Of course, that is never
performed for batch processing and this explains the bug.

I am coming late in the discussion, sorry. What I the reason why we do
not want to initialize QCoreApplication in batch mode? It would be
better if LyX was behaving similarly in all cases.

JMarc

[Enrico Forestieri]

Post by Jean-Marc Lasgouttes

Post by Enrico Forestieri

Post by Richard Heck
To be honest, I am not terribly well informed about this sort of
topic, so I am more than happy to take your word for what is right
here.

I have checked that it is Qt itself that calls setlocale(LC_ALL, "")
during QCoreApplication initialization. Of course, that is never
performed for batch processing and this explains the bug.

I am coming late in the discussion, sorry. What I the reason why we
do not want to initialize QCoreApplication in batch mode? It would
be better if LyX was behaving similarly in all cases.

That comes as part of a QApplication initialization. I think we don't
directly instantiate any QCoreApplication. In LyX.cpp there is code
that explicitly avoids that initialization for batch mode. I think that
in theory we could instantiate a QApplication for a gui-driven mode and
a QCoreApplication for batch processing. However, that was not done
for a reason that I don't know. Without a clear understanding of that
decision and of its consequences, I won't open that can of worms...

As regards LyX behaving similarly, apart this specific case (that, BTW,
only seems affecting LyX 2.1 and 2.2, most probably due to the gettext
removal, and that, BTW2, does not manifests with Qt5), I think that this
is already the case, as a QCoreApplication would only give you an event
loop that we, apparently, don't need. But I am not an expert in this
field, so take that only as a IMHO comment.

[Jean-Marc Lasgouttes]

Post by Enrico Forestieri
As regards LyX behaving similarly, apart this specific case (that, BTW,
only seems affecting LyX 2.1 and 2.2, most probably due to the gettext
removal, and that, BTW2, does not manifests with Qt5), I think that this
is already the case, as a QCoreApplication would only give you an event
loop that we, apparently, don't need. But I am not an expert in this
field, so take that only as a IMHO comment.

I remember a discussion where Georg hinted that we may have to turn
tex2lyx into a real QApplication because of problems with the QFileName
class. I wonder whether it is the same issue.

JMarc

[Georg Baum]

Post by Jean-Marc Lasgouttes

Post by Enrico Forestieri
As regards LyX behaving similarly, apart this specific case (that, BTW,
only seems affecting LyX 2.1 and 2.2, most probably due to the gettext
removal, and that, BTW2, does not manifests with Qt5), I think that this
is already the case, as a QCoreApplication would only give you an event
loop that we, apparently, don't need. But I am not an expert in this
field, so take that only as a IMHO comment.

I remember a discussion where Georg hinted that we may have to turn
tex2lyx into a real QApplication because of problems with the QFileName
class. I wonder whether it is the same issue.

Unfortunately I don't remember anymore where I read it, and a quick search
in the archives did not turn up that conversation. What I do remember is
that QFile (or QFileInfo?) relies on some initialization which is done in
QApplication, so it could be the same issue indeed.


Georg