Re: Mysterious crash
Le 29/09/2016 à 18:41, Enrico Forestieri a écrit : On Thu, Sep 29, 2016 at 12:52:02PM +0200, Guillaume Munch wrote: Thanks for the backtrace. The problem is that the variable BufferView * bv_ in ViewSourceWidget is a borrowed pointer with unclear lifetime, i.e. it will dangle. I have decided to get rid of it entirely, but this requires a few changes to the Dialog architecture and takes some time to implement (hopefully with bigger benefits). So I pushed a quick fix in the meantime. I had arrived to the same conclusion and was pushing the (perhaps simpler) attached patch, but you beated me ;) At e0e765f6a98 there is now a proper fix getting rid of the non-sensical BufferView pointer and simplifying the design a bit. The only reason why the pointer could not be removed straight away is that it was involved in a pointer comparison to check whether the bufferview had changed. I basically moved the control of the widget to the dialog, which knows the proper pointer. There is now a virtual function Dialog::on_bufferViewChanged that is called when the BufferView changes and only then. There were simpler solutions, but the new signal also helps with some code factoring and will certainly be useful in the future. Guillaume
Re: Mysterious crash
On Thu, Sep 29, 2016 at 12:52:02PM +0200, Guillaume Munch wrote:
>
> Thanks for the backtrace. The problem is that the variable BufferView *
> bv_ in ViewSourceWidget is a borrowed pointer with unclear lifetime,
> i.e. it will dangle. I have decided to get rid of it entirely, but this
> requires a few changes to the Dialog architecture and takes some time to
> implement (hopefully with bigger benefits). So I pushed a quick fix in
> the meantime.
I had arrived to the same conclusion and was pushing the (perhaps simpler)
attached patch, but you beated me ;)
--
Enrico
diff --git a/src/frontends/qt4/GuiViewSource.cpp
b/src/frontends/qt4/GuiViewSource.cpp
index db50b47..ed26f40 100644
--- a/src/frontends/qt4/GuiViewSource.cpp
+++ b/src/frontends/qt4/GuiViewSource.cpp
@@ -454,6 +454,7 @@ bool GuiViewSource::initialiseParams(string const &
/*source*/)
void GuiViewSource::updateTitle()
{
+ widget_->setBufferView(bufferview());
docstring const format = widget_->currentFormatName();
QString const title = format.empty() ? qt_("Code Preview")
: qt_("%1[[preview format name]] Preview")
Re: Mysterious crash
Le 28/09/2016 à 18:43, Enrico Forestieri a écrit : On Wed, Sep 28, 2016 at 06:30:19PM +0200, Enrico Forestieri wrote: On Wed, Sep 28, 2016 at 05:20:29PM +0200, Enrico Forestieri wrote: Steps to reproduce as follows. Make sure that the "Code Preview Pane" is closed and then: 1) open the attached document 2) open the "Code Preview Pane" 3) close the "Code Preview Pane" 4) close the document (not lyx) 5) go to 1) It will crash at step 2) on the second iteration. Does not occur on 2.2.x. Bisect points at ca586742. Backtrace: #0 0x004ab2bc in lyx::Buffer::params (this=0x0) at ../../src/Buffer.cpp:686 #1 0x00991eb4 in lyx::frontend::ViewSourceWidget::currentFormatName ( this=0x1c2a800) at ../../../../src/frontends/qt4/GuiViewSource.cpp:317 #2 0x0099313c in lyx::frontend::GuiViewSource::updateTitle ( this=0x1c1ec90) at ../../../../src/frontends/qt4/GuiViewSource.cpp:457 #3 0x009930fc in lyx::frontend::GuiViewSource::initialiseParams ( this=0x1c1ec90) at ../../../../src/frontends/qt4/GuiViewSource.cpp:450 #4 0x009dbe7e in lyx::frontend::Dialog::showData (this=0x1c1ecc0, data="") at ../../../../src/frontends/qt4/Dialog.cpp:138 #5 0x0097cf73 in lyx::frontend::GuiView::doShowDialog ( this=0x199ab80, qname=..., qdata=..., inset=0x0) at ../../../../src/frontends/qt4/GuiView.cpp:4316 #6 0x0097de1c in lyx::frontend::GuiView::qt_static_metacall ( _o=0x199ab80, _c=QMetaObject::InvokeMetaMethod, _id=16, _a=0x7fffadb0) at ./moc_GuiView.cpp:161 #7 0x76429c46 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/local/qt/5.7.0/lib/libQt5Core.so.5 #8 0x0097e0f5 in lyx::frontend::GuiView::triggerShowDialog ( this=0x199ab80, _t1=..., _t2=..., _t3=0x0) at ./moc_GuiView.cpp:237 #9 0x0097ce57 in lyx::frontend::GuiView::showDialog (this=0x199ab80, name="view-source", data="", inset=0x0) at ../../../../src/frontends/qt4/GuiView.cpp:4298 Thanks for the backtrace. The problem is that the variable BufferView * bv_ in ViewSourceWidget is a borrowed pointer with unclear lifetime, i.e. it will dangle. I have decided to get rid of it entirely, but this requires a few changes to the Dialog architecture and takes some time to implement (hopefully with bigger benefits). So I pushed a quick fix in the meantime.
Re: Mysterious crash
On Wed, Sep 28, 2016 at 06:30:19PM +0200, Enrico Forestieri wrote: > On Wed, Sep 28, 2016 at 05:20:29PM +0200, Enrico Forestieri wrote: > > Steps to reproduce as follows. > > > > Make sure that the "Code Preview Pane" is closed and then: > > 1) open the attached document > > 2) open the "Code Preview Pane" > > 3) close the "Code Preview Pane" > > 4) close the document (not lyx) > > 5) go to 1) > > > > It will crash at step 2) on the second iteration. > > Does not occur on 2.2.x. > > Bisect points at ca586742. Backtrace: #0 0x004ab2bc in lyx::Buffer::params (this=0x0) at ../../src/Buffer.cpp:686 #1 0x00991eb4 in lyx::frontend::ViewSourceWidget::currentFormatName ( this=0x1c2a800) at ../../../../src/frontends/qt4/GuiViewSource.cpp:317 #2 0x0099313c in lyx::frontend::GuiViewSource::updateTitle ( this=0x1c1ec90) at ../../../../src/frontends/qt4/GuiViewSource.cpp:457 #3 0x009930fc in lyx::frontend::GuiViewSource::initialiseParams ( this=0x1c1ec90) at ../../../../src/frontends/qt4/GuiViewSource.cpp:450 #4 0x009dbe7e in lyx::frontend::Dialog::showData (this=0x1c1ecc0, data="") at ../../../../src/frontends/qt4/Dialog.cpp:138 #5 0x0097cf73 in lyx::frontend::GuiView::doShowDialog ( this=0x199ab80, qname=..., qdata=..., inset=0x0) at ../../../../src/frontends/qt4/GuiView.cpp:4316 #6 0x0097de1c in lyx::frontend::GuiView::qt_static_metacall ( _o=0x199ab80, _c=QMetaObject::InvokeMetaMethod, _id=16, _a=0x7fffadb0) at ./moc_GuiView.cpp:161 #7 0x76429c46 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/local/qt/5.7.0/lib/libQt5Core.so.5 #8 0x0097e0f5 in lyx::frontend::GuiView::triggerShowDialog ( this=0x199ab80, _t1=..., _t2=..., _t3=0x0) at ./moc_GuiView.cpp:237 #9 0x0097ce57 in lyx::frontend::GuiView::showDialog (this=0x199ab80, name="view-source", data="", inset=0x0) at ../../../../src/frontends/qt4/GuiView.cpp:4298 -- Enrico
Re: Mysterious crash
On Wed, Sep 28, 2016 at 05:20:29PM +0200, Enrico Forestieri wrote: > Steps to reproduce as follows. > > Make sure that the "Code Preview Pane" is closed and then: > 1) open the attached document > 2) open the "Code Preview Pane" > 3) close the "Code Preview Pane" > 4) close the document (not lyx) > 5) go to 1) > > It will crash at step 2) on the second iteration. > Does not occur on 2.2.x. Bisect points at ca586742. -- Enrico
Re: Mysterious crash with a cygwin build
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Yes, it is. Thanks Jean-Marc. Done now. JMarc
Re: Mysterious crash with a cygwin build
On Tue, Mar 28, 2006 at 03:13:17PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > >> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > >> > Enrico> Latest patch (using prefixIs) attached. > >> At least the part that skips directories can go in now. It is the > >> part that avoids the crash. > >> > >> Concerning the rest, I think it matches a bugzilla entry. Could you > >> look for it? > > Enrico> You are right. I found > Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say > Enrico> that this patch fixes precisely that bug ;-) > > Enrico, I plan to apply this patch for now. Is it enoughto fix the > cygwin crash? Yes, it is. Thanks Jean-Marc. -- Enrico
Re: Mysterious crash with a cygwin build
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: >> Enrico> Latest patch (using prefixIs) attached. >> At least the part that skips directories can go in now. It is the >> part that avoids the crash. >> >> Concerning the rest, I think it matches a bugzilla entry. Could you >> look for it? Enrico> You are right. I found Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say Enrico> that this patch fixes precisely that bug ;-) Enrico, I plan to apply this patch for now. Is it enoughto fix the cygwin crash? JMarc Index: src/LaTeX.C === --- src/LaTeX.C (revision 13507) +++ src/LaTeX.C (working copy) @@ -688,7 +688,7 @@ void handleFoundFile(string const & ff, // On initial insert we want to do the update at once // since this file can not be a file generated by // the latex run. - if (fs::exists(foundfile)) + if (fs::exists(foundfile) && !fs::is_directory(foundfile)) head.insert(foundfile, true); return;
Re: Mysterious crash with a cygwin build
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> You are right. I found
> Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say
> Enrico> that this patch fixes precisely that bug
>
> Probably, yes.
>
> Enrico> Jean-Marc, what about the patch attached at bug 2344?
>
> Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=2344
>
> Enrico> It is really simple and fixes a real bug in cygwin builds.
>
> Yes, it should work with cygwin. We could apply it now, but see below.
>
> Enrico> I think that the PATH prefix handling needs to be polished
> Enrico> with cygwin. As it is now the "Use Cygwin-style paths" button
> Enrico> has no effect and one should always enter the PATH prefix in
> Enrico> posix style format.
>
> Enrico> Then, the "Use Cygwin-style paths" is a bit misleading,
> Enrico> because when it is checked LyX presents you Windows mixed
> Enrico> style paths (\ replaced by /) and when not, posix paths (seems
> Enrico> to be a reversed logic).
>
> It would be nice to understand better this "Use Cygwin-style paths"
> thing. I did not understand it very well when Kayvan introduced it,
> and I'd appreciate other views on it.
>
> If we can get rid of this, it may be that the bug above needs a
> different solution.
No, it is needed anyway. I'll try to explain why in the following.
The idea of the "Use Cygwin-style paths" button is indeed nice, because
as a cygwin application LyX should be considered as posix-compliant and
should really be viewed as if it was a unix/linux program.
But Windows users are not familiar with posix paths and would be confused,
perhaps. So, you show them a Windows-like path and they are happy.
As they stand now, things work, but some polishment is needed. For example,
here is the external_path() function in src/support/os_cygwin.C
string external_path(string const & p)
{
string dos_path;
// Translate from cygwin path syntax to dos path syntax
if (cygwin_path_fix_ && is_absolute_path(p)) {
char dp[PATH_MAX];
cygwin_conv_to_full_win32_path(p.c_str(), dp);
dos_path = !dp ? "" : dp;
}
else return p;
//No backslashes in LaTeX files
dos_path = subst(dos_path,'\\','/');
lyxerr[Debug::LATEX]
<< " ["
<< p << "]->>["
<< dos_path << ']' << endl;
return dos_path;
}
You can see that the returned path is a Windows-like path only if
cygwin_path_fix_ is true and the original is an absolute path. This is
fine and poses no problems. Depending on cygwin_path_fix_, external_path()
may be equivalent to internal_path(), as it is in os_unix.C.
However, being able to generate Windows-style paths using external_path()
is useful if you use native Windows apps, which are posix-unaware.
Also, this poses little problems if you use cygwin apps, as they
(trough cygwin1.dll) indifferently understand both Windows and posix
notations. The only problem which could arise is if the application
tries to be smart and wants to establish if a path is absolute or not.
But to what is set cygwin_path_fix_? In os_cygwin.C you'll find:
void cygwin_path_fix(bool use_cygwin_paths)
{
cygwin_path_fix_ = use_cygwin_paths;
}
where use_cygwin_paths corresponds to the state of the "Use Cygwin-style
paths" button! Now, for me cygwin-style == posix-style and I see an
inverted logic problem here.
As regards PATH prefix, as the PATH is set using setenv(), a cygwin
function, it always should be in posix format. So, the patch to bug 2344
should be applied in any case.
The polishment to be done in this case would be to let the user enter
a Windows-style PATH list in PATH prefix when "Use Cygwin-style paths"
is checked (sic!) and convert it to a posix-style PATH list behind the
scenes.
So, I think that what should be done is:
1) Rename the "Use Cygwin-style paths" button to "Use Windows-style paths"
2) Add the PATH list conversion above to the PATH prefix handling code,
such that a Windows or posix style PATH list is showed and accepted
depending on the "Use Windows-style paths" button state.
So, in conclusion, whatever is done, the patch attached to bug 2344 is
needed.
--
Enrico
Re: Mysterious crash with a cygwin build
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> You are right. I found Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say Enrico> that this patch fixes precisely that bug ;-) Probably, yes. Enrico> Jean-Marc, what about the patch attached at bug 2344? Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=2344 Enrico> It is really simple and fixes a real bug in cygwin builds. Yes, it should work with cygwin. We could apply it now, but see below. Enrico> I think that the PATH prefix handling needs to be polished Enrico> with cygwin. As it is now the "Use Cygwin-style paths" button Enrico> has no effect and one should always enter the PATH prefix in Enrico> posix style format. Enrico> Then, the "Use Cygwin-style paths" is a bit misleading, Enrico> because when it is checked LyX presents you Windows mixed Enrico> style paths (\ replaced by /) and when not, posix paths (seems Enrico> to be a reversed logic). It would be nice to understand better this "Use Cygwin-style paths" thing. I did not understand it very well when Kayvan introduced it, and I'd appreciate other views on it. If we can get rid of this, it may be that the bug above needs a different solution. JMarc
Re: Mysterious crash with a cygwin build
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> Latest patch (using prefixIs) attached. > > At least the part that skips directories can go in now. It is the part > that avoids the crash. > > Concerning the rest, I think it matches a bugzilla entry. Could you > look for it? You are right. I found http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say that this patch fixes precisely that bug ;-) Jean-Marc, what about the patch attached at bug 2344? http://bugzilla.lyx.org/show_bug.cgi?id=2344 It is really simple and fixes a real bug in cygwin builds. I think that the PATH prefix handling needs to be polished with cygwin. As it is now the "Use Cygwin-style paths" button has no effect and one should always enter the PATH prefix in posix style format. Then, the "Use Cygwin-style paths" is a bit misleading, because when it is checked LyX presents you Windows mixed style paths (\ replaced by /) and when not, posix paths (seems to be a reversed logic). Time permitting, I'll try to polish it and submit patches. -- Enrico
Re: Mysterious crash with a cygwin build
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Latest patch (using prefixIs) attached. At least the part that skips directories can go in now. It is the part that avoids the crash. Concerning the rest, I think it matches a bugzilla entry. Could you look for it? JMarc
Re: Mysterious crash with a cygwin build
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> substr(0, x) == foo
>
> we have lstring functions for that
>
> prefixIs("Index:", foo)
>
Thanks Lars.
Latest patch (using prefixIs) attached.
--
Enrico
--- src/LaTeX.C.orig2006-03-14 05:04:34.0 +0100
+++ src/LaTeX.C 2006-03-16 23:37:34.0 +0100
@@ -688,7 +688,7 @@
// On initial insert we want to do the update at once
// since this file can not be a file generated by
// the latex run.
- if (fs::exists(foundfile))
+ if (fs::exists(foundfile) && !fs::is_directory(foundfile))
head.insert(foundfile, true);
return;
@@ -750,20 +750,34 @@
static regex reg5("Writing index file ([^ ]+).*");
ifstream ifs(logfile.c_str());
+ string line2;
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by "File: xxx" only
// So I think we should use some regexps to find files instead.
// "(\([^ ]+\)" should match the "(file " variant, note
// that we can have several of these on one line.
- // "File: \([^ ]+\)" should match the "File: file" variant
-
- string token;
- getline(ifs, token);
- token = rtrim(token, "\r");
- if (token.empty())
+ // "File: \([^ ]+\)" should match the "File: file" variant.
+ // As a path name may be split across lines, we use a sliding
+ // window comprising two lines at a time while scanning files.
+
+ string const line1 = line2;
+ getline(ifs, line2);
+ if (!ifs)
+ break;
+ line2 = rtrim(line2, "\r");
+ int const len = line2.length();
+ char const endchar = len ? line2[len - 1] : 0;
+ // Check whether we can slide further down our 2-line window
+ if (line1.empty()
+ || prefixIs(line2, "File:")
+ || prefixIs(line2, "(Font)")
+ || prefixIs(line2, "Package:")
+ || prefixIs(line2, "Language:")
+ || endchar == '\\' || endchar == '/' || endchar == ')')
continue;
+ string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
Re: Mysterious crash with a cygwin build
Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Enrico Forestieri ...> writes:
> > Angus, I am a C++ newbie
>
> No! Really? Wow! You don't come across as one!
Well, I am quite proficient in C, if that counts something ;-)
> > and don't even know if getline() is some sort
> > of standard function
>
> namespace std {
> template
> basic_istream&
> getline(basic_istream& istr,
> basic_string& str);
> }
;-)
At the time, I only had a glance at a 1993 edition of the Stroustroup
book (I still have it somewhere), and I think the word template doesn't
even appeared there ;-)
This is arabic as far as I am concerned (but I can guess at it ;-)).
However, my C++ semi-ignorance doesn't stop me from hacking C++ sources.
I only do what I know works for sure...
I am not a programmer but I know quite a slew of languages, even some
assembly. Recently I learned python, that enough for setting up a web
site to support a workshop I organized. I offered the possibility to
submit papers in LyX, using a custom layout, and even got 4 submissions
out of 31 (9 were in word and the remaining in LaTeX).
> > or a LyX support function ...
> > > + // Also, move the line1.empty() test to the place
> > > + // where you assign line1.
> >
> > Really not, if I want to avoid an endless loop
>
> :)
>
> > Attached the revised patch.
>
> Looks good to me. Since it fixes a crash, I'd get JMarc to shove it in the
> 1.4.x
> tree. That means you'll need to enlist the help of someone thorough to test
> it :)
Well, it is a so simple patch... Simply catenate two lines before
applying the already devised regexps to account for splitted file names...
Anyway, any volunteers?
--
Enrico
Re: Mysterious crash with a cygwin build
Angus Leeming <[EMAIL PROTECTED]> writes:
| Enrico Forestieri <[EMAIL PROTECTED]> writes:
| > Angus, I am a C++ newbie
|
| No! Really? Wow! You don't come across as one!
|
| > and don't even know if getline() is some sort
| > of standard function
|
| namespace std {
| template
| basic_istream&
| getline(basic_istream& istr,
| basic_string& str);
| }
|
| > or a LyX support function ...
| > > + // Also, move the line1.empty() test to the place
| > > + // where you assign line1.
| >
| > Really not, if I want to avoid an endless loop
|
| :)
|
| > Attached the revised patch.
|
| Looks good to me. Since it fixes a crash, I'd get JMarc to shove it in the
1.4.x
| tree. That means you'll need to enlist the help of someone thorough to test
it :)
substr(0, x) == foo
we have lstring functions for that
prefixIs("Index:", foo)
--
Lgb
Re: Mysterious crash with a cygwin build
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> Angus, I am a C++ newbie
No! Really? Wow! You don't come across as one!
> and don't even know if getline() is some sort
> of standard function
namespace std {
template
basic_istream&
getline(basic_istream& istr,
basic_string& str);
}
> or a LyX support function ...
> > + // Also, move the line1.empty() test to the place
> > + // where you assign line1.
>
> Really not, if I want to avoid an endless loop
:)
> Attached the revised patch.
Looks good to me. Since it fixes a crash, I'd get JMarc to shove it in the 1.4.x
tree. That means you'll need to enlist the help of someone thorough to test it
:)
Angus
Re: Mysterious crash with a cygwin build
Angus Leeming <[EMAIL PROTECTED]> writes:
> I think that this version is more robust, but I haven't tried it out...
It works ;-)
> Angus
>
> -750,20 +750,30
> static regex reg5("Writing index file ([^ ]+).*");
>
> ifstream ifs(logfile.c_str());
> - string line1, line2 = "";
> + string line2;
> while (ifs) {
> // Ok, the scanning of files here is not sufficient.
> // Sometimes files are named by "File: xxx" only
> // So I think we should use some regexps to find files
> instead.
> // "(\([^ ]+\)" should match the "(file " variant, note
> // that we can have several of these on one line.
> // "File: \([^ ]+\)" should match the "File: file" variant.
> // As a path name may be split across lines, we use a sliding
> // window comprising two lines at a time while scanning files.
>
> - line1 = line2;
> + string const line1 = line2;
> getline(ifs, line2);
> + if (!ifs)
> + break;
> + // Is this rtrim needed? Doesn't getline() do it for you?
Angus, I am a C++ newbie and don't even know if getline() is some sort
of standard function or a LyX support function ...
The rtrim was already there and I didn't dare to get rid of it ;-)
> line2 = rtrim(line2, "\r");
> + // I believe that the coding style is "int const len"...
Ok, changed.
> const int len = line2.length();
> const char endchar = len ? line2[len - 1] : 0;
> + // Isn't line1 empty on the first iteration of this loop?
Yes, it is.
> + // Also, move the line1.empty() test to the place
> + // where you assign line1.
Really not, if I want to avoid an endless loop ;-)
I think that it logically belongs here because these are all checks to
see if we can move further down our sliding window.
> if (line1.empty()
> || line2.substr(0,8) == "Package:"
> || line2.substr(0,5) == "File:"
> || line2.substr(0,9) == "Language:"
> || endchar == '\\' || endchar == '/' || endchar == ')')
> continue;
>
> string token = line1 + line2;
> smatch sub;
>
> if (regex_match(token, sub, reg1)) {
>
Attached the revised patch.
--
Enrico
--- src/LaTeX.C.orig2006-03-14 05:04:34.0 +0100
+++ src/LaTeX.C 2006-03-16 21:04:04.0 +0100
@@ -688,7 +688,7 @@
// On initial insert we want to do the update at once
// since this file can not be a file generated by
// the latex run.
- if (fs::exists(foundfile))
+ if (fs::exists(foundfile) && !fs::is_directory(foundfile))
head.insert(foundfile, true);
return;
@@ -750,20 +750,34 @@
static regex reg5("Writing index file ([^ ]+).*");
ifstream ifs(logfile.c_str());
+ string line2;
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by "File: xxx" only
// So I think we should use some regexps to find files instead.
// "(\([^ ]+\)" should match the "(file " variant, note
// that we can have several of these on one line.
- // "File: \([^ ]+\)" should match the "File: file" variant
-
- string token;
- getline(ifs, token);
- token = rtrim(token, "\r");
- if (token.empty())
+ // "File: \([^ ]+\)" should match the "File: file" variant.
+ // As a path name may be split across lines, we use a sliding
+ // window comprising two lines at a time while scanning files.
+
+ string const line1 = line2;
+ getline(ifs, line2);
+ if (!ifs)
+ break;
+ line2 = rtrim(line2, "\r");
+ int const len = line2.length();
+ char const endchar = len ? line2[len - 1] : 0;
+ // Check whether we can slide further down our 2-line window
+ if (line1.empty()
+ || line2.substr(0,5) == "File:"
+ || line2.substr(0,6) == "(Font)"
+ || line2.substr(0,8) == "Package:"
+ || line2.substr(0,9) == "Language:"
+ || endchar == '\\' || endchar == '/' || endchar == ')')
continue;
+ string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
Re: Mysterious crash with a cygwin build
Enrico Forestieri wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>> > I'll try to come up with a patch to the LaTeX::deplog() function in
>> > src/LaTeX.C.
>>
>> Way to go!
>
> ;-)
>
> Here is the patch. Please test, it works for me. The only drawback which
> I can foresee is that a file *may* be passed two times to
> handleFoundFile() but I think it is better than before, when a file could
> be missed.
I think that this version is more robust, but I haven't tried it out...
Angus
@@ -750,20 +750,30 @@
static regex reg5("Writing index file ([^ ]+).*");
ifstream ifs(logfile.c_str());
- string line1, line2 = "";
+ string line2;
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by "File: xxx" only
// So I think we should use some regexps to find files instead.
// "(\([^ ]+\)" should match the "(file " variant, note
// that we can have several of these on one line.
// "File: \([^ ]+\)" should match the "File: file" variant.
// As a path name may be split across lines, we use a sliding
// window comprising two lines at a time while scanning files.
- line1 = line2;
+ string const line1 = line2;
getline(ifs, line2);
+ if (!ifs)
+ break;
+ // Is this rtrim needed? Doesn't getline() do it for you?
line2 = rtrim(line2, "\r");
+ // I believe that the coding style is "int const len"...
const int len = line2.length();
const char endchar = len ? line2[len - 1] : 0;
+ // Isn't line1 empty on the first iteration of this loop?
+ // Also, move the line1.empty() test to the place
+ // where you assign line1.
if (line1.empty()
|| line2.substr(0,8) == "Package:"
|| line2.substr(0,5) == "File:"
|| line2.substr(0,9) == "Language:"
|| endchar == '\\' || endchar == '/' || endchar == ')')
continue;
string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
--
Angus
Re: Mysterious crash with a cygwin build
Angus Leeming <[EMAIL PROTECTED]> writes:
> > I'll try to come up with a patch to the LaTeX::deplog() function in
> > src/LaTeX.C.
>
> Way to go!
;-)
Here is the patch. Please test, it works for me. The only drawback which
I can foresee is that a file *may* be passed two times to handleFoundFile()
but I think it is better than before, when a file could be missed.
--
Enrico
--- src/LaTeX.C.orig2006-03-14 05:04:34.0 +0100
+++ src/LaTeX.C 2006-03-16 19:29:24.0 +0100
@@ -688,7 +688,7 @@
// On initial insert we want to do the update at once
// since this file can not be a file generated by
// the latex run.
- if (fs::exists(foundfile))
+ if (fs::exists(foundfile) && !fs::is_directory(foundfile))
head.insert(foundfile, true);
return;
@@ -750,20 +750,30 @@
static regex reg5("Writing index file ([^ ]+).*");
ifstream ifs(logfile.c_str());
+ string line1, line2 = "";
while (ifs) {
// Ok, the scanning of files here is not sufficient.
// Sometimes files are named by "File: xxx" only
// So I think we should use some regexps to find files instead.
// "(\([^ ]+\)" should match the "(file " variant, note
// that we can have several of these on one line.
- // "File: \([^ ]+\)" should match the "File: file" variant
-
- string token;
- getline(ifs, token);
- token = rtrim(token, "\r");
- if (token.empty())
+ // "File: \([^ ]+\)" should match the "File: file" variant.
+ // As a path name may be split across lines, we use a sliding
+ // window comprising two lines at a time while scanning files.
+
+ line1 = line2;
+ getline(ifs, line2);
+ line2 = rtrim(line2, "\r");
+ const int len = line2.length();
+ const char endchar = len ? line2[len - 1] : 0;
+ if (line1.empty()
+ || line2.substr(0,8) == "Package:"
+ || line2.substr(0,5) == "File:"
+ || line2.substr(0,9) == "Language:"
+ || endchar == '\\' || endchar == '/' || endchar == ')')
continue;
+ string token = line1 + line2;
smatch sub;
if (regex_match(token, sub, reg1)) {
Re: Mysterious crash with a cygwin build
Enrico Forestieri <[EMAIL PROTECTED]> writes: > )) (C:\texmf\tex\latex\pgf\basiclayer\pgfcore.sty > (C:\texmf\tex\latex\graphics\ > graphicx.sty > Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR) > ... > Notice that the line ending in "(C:\texmf\tex\latex\graphics\" really > ends with a linebreak, such that graphicx.sty is not wrapped but it is > on the next line (I checked it editing with vim the file). > So, instead of "C:\texmf\tex\latex\graphics\graphicx.sty" the regexps > extract simply "C:\texmf\tex\latex\graphics\", upon which the crc > computation is tried, leading to a crash in cygwin. Great detective work, Enrico. Are all these ".sty" lines in the log file followed by "Package:"? Perhaps you could use that as the delimiter? > I'll try to come up with a patch to the LaTeX::deplog() function in > src/LaTeX.C. Way to go! Angus
Re: Mysterious crash with a cygwin build
Angus Leeming <[EMAIL PROTECTED]> writes: > Enrico Forestieri ...> writes: > > Computing crc of "/c/texmf/tex/latex/graphics/" > > Abort (core dumped) > > > > I tried the same with a mingw build and got that it also tried computing > > the crc of the same directory, but in this case no crash was occurring. > > > > As it seems really strange that the crc of a directory is needed I tought > > that it is better if I still stick with this mailing list before going > > to bug the cygwin people > > General screw up! Now you just have to find out why and how :) Uhm, I think I found why and how, only I am not sure that I will be able to cleanly fix it... -- Enrico
Re: Mysterious crash with a cygwin build
Enrico Forestieri <[EMAIL PROTECTED]> writes: > I made a self-contained executable from lyxsum.C and tried it on every > file in the texmf tree but did not succeed in crashing it. So I added > some debugging statements to src/support/lyxsum.C to see what file was > triggering the crash and to my suprise it was not a file but a directory... > > $ src/lyx-qt.exe > New counter already exists: section > Locale en_US could not be set > beamericonbook.pdf > beamericonbook.20.pdf > beamericonarticle.pdf > beamericonarticle.20.pdf > Computing crc of "/tmp/lyx_tmpdir1456cHRIK5/lyx_tmpbuf0/beamer-crash.tex" > Computing crc of "/c/texmf/tex/latex/beamer/beamer.cls" > Computing crc of "/c/texmf/tex/latex/beamer/beamerbasemodes.sty" > Computing crc of "/c/texmf/tex/latex/beamer/beamerbasedecode.sty" > Computing crc of "/c/texmf/tex/latex/beamer/beamerbaseoptions.sty" > Computing crc of "/c/texmf/tex/latex/graphics/keyval.sty" > Computing crc of "/c/texmf/tex/latex/pgf/basiclayer/pgfcore.sty" > Computing crc of "/c/texmf/tex/latex/graphics/" > Abort (core dumped) > > I tried the same with a mingw build and got that it also tried computing > the crc of the same directory, but in this case no crash was occurring. > > As it seems really strange that the crc of a directory is needed I tought > that it is better if I still stick with this mailing list before going > to bug the cygwin people I think I found the source of the problem. LyX reads the log file generated by running latex to build a list of files used as dependency. The files are extracted from the log by using a bunch of regular expressions. These regexps sometime fail to correctly extract a file name if it is truncated between lines. For example, the following is an excerpt from the log file /tmp/lyx_tmpdir1456cHRIK5/lyx_tmpbuf0/beamer-crash.log generated by MikTeX and leading to the last files above, just before the crash: ... (C:\texmf\tex\latex\beamer\beamerbaseoptions.sty Package: beamerbaseoptions 2004/11/15 (rcs-revision 1.7) (C:\texmf\tex\latex\graphics\keyval.sty Package: keyval 1999/03/16 v1.13 key=value parser (DPC) [EMAIL PROTECTED]@=\toks14 )) (C:\texmf\tex\latex\pgf\basiclayer\pgfcore.sty (C:\texmf\tex\latex\graphics\ graphicx.sty Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR) ... Notice that the line ending in "(C:\texmf\tex\latex\graphics\" really ends with a linebreak, such that graphicx.sty is not wrapped but it is on the next line (I checked it editing with vim the file). So, instead of "C:\texmf\tex\latex\graphics\graphicx.sty" the regexps extract simply "C:\texmf\tex\latex\graphics\", upon which the crc computation is tried, leading to a crash in cygwin. I'll try to come up with a patch to the LaTeX::deplog() function in src/LaTeX.C. -- Enrico
Re: Mysterious crash with a cygwin build
Enrico Forestieri <[EMAIL PROTECTED]> writes: > Computing crc of "/c/texmf/tex/latex/graphics/" > Abort (core dumped) > > I tried the same with a mingw build and got that it also tried computing > the crc of the same directory, but in this case no crash was occurring. > > As it seems really strange that the crc of a directory is needed I tought > that it is better if I still stick with this mailing list before going > to bug the cygwin people General screw up! Now you just have to find out why and how :) Angus
Re: Mysterious crash with a cygwin build
Angus Leeming <[EMAIL PROTECTED]> writes: > If memory serves me right, this function is pretty self contained. You should > be > able to add a main() that just calls it with the offending file. "gcc -E" the > file to create the full source listing and you'll be able to give 'em the code > that triggers the fault. I made a self-contained executable from lyxsum.C and tried it on every file in the texmf tree but did not succeed in crashing it. So I added some debugging statements to src/support/lyxsum.C to see what file was triggering the crash and to my suprise it was not a file but a directory... $ src/lyx-qt.exe New counter already exists: section Locale en_US could not be set beamericonbook.pdf beamericonbook.20.pdf beamericonarticle.pdf beamericonarticle.20.pdf Computing crc of "/tmp/lyx_tmpdir1456cHRIK5/lyx_tmpbuf0/beamer-crash.tex" Computing crc of "/c/texmf/tex/latex/beamer/beamer.cls" Computing crc of "/c/texmf/tex/latex/beamer/beamerbasemodes.sty" Computing crc of "/c/texmf/tex/latex/beamer/beamerbasedecode.sty" Computing crc of "/c/texmf/tex/latex/beamer/beamerbaseoptions.sty" Computing crc of "/c/texmf/tex/latex/graphics/keyval.sty" Computing crc of "/c/texmf/tex/latex/pgf/basiclayer/pgfcore.sty" Computing crc of "/c/texmf/tex/latex/graphics/" Abort (core dumped) I tried the same with a mingw build and got that it also tried computing the crc of the same directory, but in this case no crash was occurring. As it seems really strange that the crc of a directory is needed I tought that it is better if I still stick with this mailing list before going to bug the cygwin people ;-) -- Enrico
Re: Mysterious crash with a cygwin build
Angus Leeming <[EMAIL PROTECTED]> writes: > If memory serves me right, this function is pretty self contained. You should > be > able to add a main() that just calls it with the offending file. "gcc -E" the > file to create the full source listing and you'll be able to give 'em the code > that triggers the fault. Thank you for the tip, Angus. I'll elaborate on that. What is strange is that the crash seems to occur only when trying to preview a beamer document. -- Enrico
Re: Mysterious crash with a cygwin build
Enrico Forestieri <[EMAIL PROTECTED]> writes: > > When trying to preview a beamer document I get a crash with a cygwin build. > I attach a bt at the bottom. Am I right that the crash is occurring inside > cygwin1.dll? Just ignore the first two false SEGFAULTS, it's a known > problem with gdb in cygwin, solved by a couple of "cont". > > I am quite sure it is a cygwin1.dll fault, but want to be really sure > before I report the problem to their really picky mailing list > Something is going wrong when performing a check sum on some file. Perhaps add some diagnostic info so you can ascertain what file: #20 0x009dd6b0 in check_exception_spec () #21 0x009de467 in __cxa_throw () #22 0x009d5eee in std::__throw_ios_failure () #23 0x00a9333d in std::basic_filebuf >::underflow () #24 0x00af49b9 in std::for_each >, boost::crc_optimal<32u, 79764919u, 4294967295u, 4294967295u, true, true> > () #25 0x009b5557 in lyx::support::sum () If memory serves me right, this function is pretty self contained. You should be able to add a main() that just calls it with the offending file. "gcc -E" the file to create the full source listing and you'll be able to give 'em the code that triggers the fault. Angus
