The Mystery Crash Is NOT Triggered By Auto-Save

[Richard Heck]

In a different thread, Paul Rubin reported the same crash (\begin_inset
Tabular) that we've seen from other people but also reports that he does
NOT have auto-save enabled. Since auto-save has been the target of
suspicion, that's an important datum.

In his case, and in some other cases, however, the LyX file itself is
corrupt. That seems to imply that the crash happens as a result of
trying to save the document: Otherwise, the LyX file would be
unaffected. Then of course one would expect to see the same crash when
the document was auto-saved. So people with auto-save enabled will see
this crash more often, though it would not in that case corrupt the
original LyX file.

So: Having auto-save enabled makes it more likely one will see this
crash. But auto-save is not responsible. One can also see it just by
doing an ordinary save.

Richard

[Richard Heck]

Post by Richard Heck
In a different thread, Paul Rubin reported the same crash
(\begin_inset Tabular) that we've seen from other people but also
reports that he does NOT have auto-save enabled. Since auto-save has
been the target of suspicion, that's an important datum.
In his case, and in some other cases, however, the LyX file itself is
corrupt. That seems to imply that the crash happens as a result of
trying to save the document: Otherwise, the LyX file would be
unaffected. Then of course one would expect to see the same crash when
the document was auto-saved. So people with auto-save enabled will see
this crash more often, though it would not in that case corrupt the
original LyX file.
So: Having auto-save enabled makes it more likely one will see this
crash. But auto-save is not responsible. One can also see it just by
doing an ordinary save.

The fact that everything always ends with \begin_inset Tabular confuses
me. As soon as we write that, we go into Tabular::write(). And, assuming
we actually make it there, the next thing we do is output "<lyxtabular "
and a bunch of similar info. Why doesn't any of that show up in the
output file? Is there some kind of buffering going on? If so, would it
be worth disabling that, so the corrupted files would give us more
information about exactly where we are crashing? It's hard to see that
there is anything in Tabular::write() itself that could cause a crash,
except bad vector access, and it's hard to see why that would happen so
intermittently. My guess is that the crash comes when writing some
particular cell, but who knows?

Richard

[Jürgen Spitzmüller]

Post by Richard Heck
The fact that everything always ends with \begin_inset Tabular confuses
me. As soon as we write that, we go into Tabular::write(). And, assuming
we actually make it there, the next thing we do is output "<lyxtabular "
and a bunch of similar info. Why doesn't any of that show up in the
output file? Is there some kind of buffering going on? If so, would it
be worth disabling that, so the corrupted files would give us more
information about exactly where we are crashing? It's hard to see that
there is anything in Tabular::write() itself that could cause a crash,
except bad vector access, and it's hard to see why that would happen so
intermittently. My guess is that the crash comes when writing some
particular cell, but who knows?

FWIW, there has only been one single commit that touches Tabular::write(),
namely this:
http://www.lyx.org/trac/changeset/304655a75/lyxgit

And this looks innocent to me. The only thing is that the
convert<string>(rotate) conversion is superfluous, since we have a
write_attribute(string, int) method. But this can hardly be the cause of our
woes.

Jürgen

[Jean-Marc Lasgouttes]

Post by Richard Heck
The fact that everything always ends with \begin_inset Tabular confuses
me. As soon as we write that, we go into Tabular::write(). And, assuming
we actually make it there, the next thing we do is output "<lyxtabular "
and a bunch of similar info. Why doesn't any of that show up in the
output file? Is there some kind of buffering going on? If so, would it
be worth disabling that, so the corrupted files would give us more
information about exactly where we are crashing? It's hard to see that
there is anything in Tabular::write() itself that could cause a crash,
except bad vector access, and it's hard to see why that would happen so
intermittently. My guess is that the crash comes when writing some
particular cell, but who knows?

Note that InsetTabular::write flushes the stream with a endl, and that
Tabular::write does not use endl at all. Actually, I m not sure that
there are many places where endl is used as in this case. And if
InsetTabular::write is the only one to use endl, then it may not be a
surprise that the truncated files stop there.

IOW, it may be that the bug is not really related to tabular inset.

One step in resolution may be to flush the stream after each end_inset
and after each paragraph.

jmARC

[Jürgen Spitzmüller]

Post by Jean-Marc Lasgouttes
Note that InsetTabular::write flushes the stream with a endl, and that
Tabular::write does not use endl at all. Actually, I m not sure that
there are many places where endl is used as in this case. And if
InsetTabular::write is the only one to use endl, then it may not be a
surprise that the truncated files stop there.
IOW, it may be that the bug is not really related to tabular inset.

This sounds very plausible, indeed.

Post by Jean-Marc Lasgouttes
One step in resolution may be to flush the stream after each end_inset
and after each paragraph.

I agree. Is there any disadvantage of flushing the stream more often than we do
now?

Jürgen

Post by Jean-Marc Lasgouttes
jmARC

[JeanMarc Lasgouttes]

It is a matter of speed AFAIK.

An unrelated safety belt would be to save the file under a temporary name (in the same directory) and rename it to the proper name on success.

JMarc

Post by Jean-Marc Lasgouttes

Post by Jean-Marc Lasgouttes
One step in resolution may be to flush the stream after each

end_inset

Post by Jean-Marc Lasgouttes
and after each paragraph.

I agree. Is there any disadvantage of flushing the stream more often than we do
now?

[Richard Heck]

Post by JeanMarc Lasgouttes
It is a matter of speed AFAIK.
An unrelated safety belt would be to save the file under a temporary name (in the same directory) and rename it to the proper name on success.

I propose to commit the attached. The effect is: (i) We always create a
backup file in the current directory, but in the backup directory if
"Make Backups" is true; (ii) If we are unable to do so, we ask the user
if s'he wants to proceed; (iii) We delete the backup file after a
successful save, unless "Make Backups" is true.

Richard

[Richard Heck]

Post by Jean-Marc Lasgouttes

Post by Richard Heck
The fact that everything always ends with \begin_inset Tabular confuses
me. As soon as we write that, we go into Tabular::write(). And, assuming
we actually make it there, the next thing we do is output
"<lyxtabular "
and a bunch of similar info. Why doesn't any of that show up in the
output file? Is there some kind of buffering going on? If so, would it
be worth disabling that, so the corrupted files would give us more
information about exactly where we are crashing? It's hard to see that
there is anything in Tabular::write() itself that could cause a crash,
except bad vector access, and it's hard to see why that would happen so
intermittently. My guess is that the crash comes when writing some
particular cell, but who knows?

Note that InsetTabular::write flushes the stream with a endl, and that
Tabular::write does not use endl at all. Actually, I m not sure that
there are many places where endl is used as in this case. And if
InsetTabular::write is the only one to use endl, then it may not be a
surprise that the truncated files stop there.
IOW, it may be that the bug is not really related to tabular inset.

Yes, that's true. Though, in most of the reports I have seen of this
crash, the user was doing something with a table when the crash
occurred. It's a wild guess, but I'm wondering if putting the cursor
into a certain cell (multirow, multicolumn?) and doing something there
could leave the table in an inconsistent state, and the attempt to write
it then crashes.

Post by Jean-Marc Lasgouttes
One step in resolution may be to flush the stream after each end_inset
and after each paragraph.

I think this would be a very good idea.

Richard

[Jürgen Spitzmüller]

Post by Richard Heck
Yes, that's true. Though, in most of the reports I have seen of this
crash, the user was doing something with a table when the crash
occurred. It's a wild guess, but I'm wondering if putting the cursor
into a certain cell (multirow, multicolumn?) and doing something there
could leave the table in an inconsistent state, and the attempt to write
it then crashes.

To me (and also others such as Uwe) the crash also occurred when working
outside and far off tables. However, we never had a case where the document
contained no table.

Jürgen

[Richard Heck]

Post by Jürgen Spitzmüller

Post by Richard Heck
Yes, that's true. Though, in most of the reports I have seen of this
crash, the user was doing something with a table when the crash
occurred. It's a wild guess, but I'm wondering if putting the cursor
into a certain cell (multirow, multicolumn?) and doing something there
could leave the table in an inconsistent state, and the attempt to write
it then crashes.

To me (and also others such as Uwe) the crash also occurred when working
outside and far off tables. However, we never had a case where the document
contained no table.

OK, that's worth knowing.

Richard

[Jean-Marc Lasgouttes]

Post by Richard Heck

Post by Jürgen Spitzmüller

Post by Richard Heck
Yes, that's true. Though, in most of the reports I have seen of this
crash, the user was doing something with a table when the crash
occurred. It's a wild guess, but I'm wondering if putting the cursor
into a certain cell (multirow, multicolumn?) and doing something there
could leave the table in an inconsistent state, and the attempt to write
it then crashes.

To me (and also others such as Uwe) the crash also occurred when working
outside and far off tables. However, we never had a case where the document
contained no table.

OK, that's worth knowing.

Assuming that the cell_info vector is not clobbered by rogue memory
overwriting, my next bet would be a bad (null?) inset pointer in
cell_info[r][c].inset->write(os);

I see that this inset is shared, but with what other holder?

JMarc

[Richard Heck]

Post by Jean-Marc Lasgouttes

Post by Richard Heck

Post by Jürgen Spitzmüller

Post by Richard Heck
Yes, that's true. Though, in most of the reports I have seen of this
crash, the user was doing something with a table when the crash
occurred. It's a wild guess, but I'm wondering if putting the cursor
into a certain cell (multirow, multicolumn?) and doing something there
could leave the table in an inconsistent state, and the attempt to write
it then crashes.

To me (and also others such as Uwe) the crash also occurred when working
outside and far off tables. However, we never had a case where the document
contained no table.

OK, that's worth knowing.

Assuming that the cell_info vector is not clobbered by rogue memory
overwriting, my next bet would be a bad (null?) inset pointer in
cell_info[r][c].inset->write(os);
I see that this inset is shared, but with what other holder?

It's hard to tell from the history now why it is like that. My guess
would be that it was introduced, possibly by me, to deal with copy and
paste sorts of issues. I see a difference, though, in the behavior of
the copy constructor, which clones the InsetTableCell, and the
assignment constructor, which does not.

Still, it's puzzling why this would have appeared now. What did we change?

I'm appending a diff of InsetTabular.cpp against 2.0.x, in case that helps.

Richard

[Richard Heck]

Post by Richard Heck
I'm appending a diff of InsetTabular.cpp against 2.0.x, in case that helps.

That last diff was backwards.

rh

[Jean-Marc Lasgouttes]

Post by Richard Heck

Post by Richard Heck
I'm appending a diff of InsetTabular.cpp against 2.0.x, in case that helps.

That last diff was backwards.

I was trying to figure out the command to do that. How did you do it?

JMarc

[Richard Heck]

Post by Jean-Marc Lasgouttes

Post by Richard Heck

Post by Richard Heck
I'm appending a diff of InsetTabular.cpp against 2.0.x, in case that helps.

That last diff was backwards.

I was trying to figure out the command to do that. How did you do it?

Just diff. I have two trees: one for stable, one for devel, as its just
easier that way.

Richard

[Jean-Marc Lasgouttes]

Post by Richard Heck

Post by Jean-Marc Lasgouttes
I was trying to figure out the command to do that. How did you do it?

Just diff. I have two trees: one for stable, one for devel, as its just
easier that way.

Cheater!

JMarc

[Jürgen Spitzmüller]

Post by Richard Heck

Post by Jürgen Spitzmüller

Post by Richard Heck
Yes, that's true. Though, in most of the reports I have seen of this
crash, the user was doing something with a table when the crash
occurred. It's a wild guess, but I'm wondering if putting the cursor
into a certain cell (multirow, multicolumn?) and doing something there
could leave the table in an inconsistent state, and the attempt to write
it then crashes.

To me (and also others such as Uwe) the crash also occurred when working
outside and far off tables. However, we never had a case where the document
contained no table.

OK, that's worth knowing.

BTW, I had a closer look at some corrupted files, and what is interesting
is that the file does not end at the first tabular in the document. Uwe's
test document on trac and a file a user sent me both contain complete
tabular(s) before the file is truncated.

JÃŒrgen

Post by Richard Heck
Richard

[Richard Heck]

Post by Richard Heck
Yes, that's true. Though, in most of the reports I have
seen of this
crash, the user was doing something with a table when the crash
occurred. It's a wild guess, but I'm wondering if putting
the cursor
into a certain cell (multirow, multicolumn?) and doing
something there
could leave the table in an inconsistent state, and the
attempt to write
it then crashes.
To me (and also others such as Uwe) the crash also occurred when working
outside and far off tables. However, we never had a case where the document
contained no table.
OK, that's worth knowing.
BTW, I had a closer look at some corrupted files, and what is
interesting is that the file does not end at the first tabular in the
document. Uwe's test document on trac and a file a user sent me both
contain complete tabular(s) before the file is truncated.

I'm guessing there is some corruption of the data structures connected
with some table. It needn't be the first one, and could have to do with
some special feature of that particular table: multirow, long table,
whatever. Or, as JMarc has suggested, it might not be in the table at all.

Richard

[stefano franchi]

Post by Richard Heck

Post by Jean-Marc Lasgouttes

Post by Richard Heck
The fact that everything always ends with \begin_inset Tabular confuses
me. As soon as we write that, we go into Tabular::write(). And, assuming
we actually make it there, the next thing we do is output "<lyxtabular "
and a bunch of similar info. Why doesn't any of that show up in the
output file? Is there some kind of buffering going on? If so, would it
be worth disabling that, so the corrupted files would give us more
information about exactly where we are crashing? It's hard to see that
there is anything in Tabular::write() itself that could cause a crash,
except bad vector access, and it's hard to see why that would happen so
intermittently. My guess is that the crash comes when writing some
particular cell, but who knows?

Note that InsetTabular::write flushes the stream with a endl, and that
Tabular::write does not use endl at all. Actually, I m not sure that there
are many places where endl is used as in this case. And if
InsetTabular::write is the only one to use endl, then it may not be a
surprise that the truncated files stop there.
IOW, it may be that the bug is not really related to tabular inset.

Yes, that's true. Though, in most of the reports I have seen of this
crash, the user was doing something with a table when the crash occurred.
It's a wild guess, but I'm wondering if putting the cursor into a certain
cell (multirow, multicolumn?) and doing something there could leave the
table in an inconsistent state, and the attempt to write it then crashes.

I am getting a lot of crashes with 2.1, and they are completely unrelated
to tables. I only use 2.1 for the LyX/Word GSOC project, and I have it
always open with the project's test files open. No tables. I may do some
work on the files once a day, so it's not heavily used. LyX crashes at
least once a day, often more than once.

The crash message is the usual, uninformative "SIGSEV signal caught...". I
have not experienced any data loss, but then again, I would not expect any,
as my edits to the open files are minimal and I save immediately. I do have
auto-save on at the default 5 minutes.

Lastly, crashes are not system-generated, they always occur immediately
after some action (opening a menu, switching tabs, etc.).

This behavior may be totally unrelated to the problem under discussion, but
I thought I would add another data point.


S.
--
__________________________________________________
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
--
__________________________________________________
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

[Jürgen Spitzmüller]

Post by stefano franchi
Lastly, crashes are not system-generated, they always occur immediately
after some action (opening a menu, switching tabs, etc.).

This sounds like bugs that have been resolved for 2.1.1 (especially the
menu-related crashes).

But to be sure, we'd need backtraces.

JÃŒrgen
<http://stefano.cleinias.org>

[stefano franchi]

Post by stefano franchi
Lastly, crashes are not system-generated, they always occur immediately

Post by stefano franchi
after some action (opening a menu, switching tabs, etc.).

This sounds like bugs that have been resolved for 2.1.1 (especially the
menu-related crashes).
But to be sure, we'd need backtraces.

Good point. Rebuilding with latest version right now.

Cheers,

S.
--
__________________________________________________
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

[Cyrille Artho]

Dear all,
It looks like in the long term, a grammar-based random document generator
for LyX would be very useful for testing. The "grammar" would contain rules
about how a document looks like: Title, authors, abstract, sections with
subsections and text/tables/figures/equations. Tables/figures/equations
would again be generated by other rules.

Of course content does not matter, as long as the result is a valid .lyx
file. For testing, the result would be loaded by lyx and saved again. This
would ensure a document does not get corrupted by saving, no matter how
strange it is.

However, it is a significant effort to build a decent document generator
that is useful for such testing... something that may fit for GSoC, though.
I'll keep this in mind for 2015.

[stefano franchi]

Post by Cyrille Artho
Dear all,
It looks like in the long term, a grammar-based random document generator
for LyX would be very useful for testing. The "grammar" would contain rules
about how a document looks like: Title, authors, abstract, sections with
subsections and text/tables/figures/equations. Tables/figures/equations
would again be generated by other rules.
Of course content does not matter, as long as the result is a valid .lyx
file. For testing, the result would be loaded by lyx and saved again. This
would ensure a document does not get corrupted by saving, no matter how
strange it is.
However, it is a significant effort to build a decent document generator
that is useful for such testing... something that may fit for GSoC, though.
I'll keep this in mind for 2015.

Excellent idea, although the sheer variety of things to test makes the
problem hard. Perhaps this would be a good starting point:

http://pdos.csail.mit.edu/scigen/

S.
--
__________________________________________________
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

[Cyrille Artho]

Post by Cyrille Artho
Dear all,
It looks like in the long term, a grammar-based random document
generator for LyX would be very useful for testing. The "grammar" would
contain rules about how a document looks like: Title, authors,
abstract, sections with subsections and text/tables/figures/equations.
Tables/figures/equations would again be generated by other rules.
Of course content does not matter, as long as the result is a valid
.lyx file. For testing, the result would be loaded by lyx and saved
again. This would ensure a document does not get corrupted by saving,
no matter how strange it is.
However, it is a significant effort to build a decent document
generator that is useful for such testing... something that may fit for
GSoC, though. I'll keep this in mind for 2015.
Excellent idea, although the sheer variety of things to test makes the
http://pdos.csail.mit.edu/scigen/
S.

Yes, that could be a starting point, although the code may not be easy to
edit. In any case, we'd need LyX files, and also tables (perhaps even
equations) that are non-trivial but still syntactically correct.

[stefano franchi]

Post by Cyrille Artho
Dear all,
It looks like in the long term, a grammar-based random document
generator for LyX would be very useful for testing. The "grammar" would
contain rules about how a document looks like: Title, authors,
abstract, sections with subsections and text/tables/figures/equations.
Tables/figures/equations would again be generated by other rules.
Of course content does not matter, as long as the result is a valid
.lyx file. For testing, the result would be loaded by lyx and saved
again. This would ensure a document does not get corrupted by saving,
no matter how strange it is.
However, it is a significant effort to build a decent document
generator that is useful for such testing... something that may fit for
GSoC, though. I'll keep this in mind for 2015.
Excellent idea, although the sheer variety of things to test makes the
http://pdos.csail.mit.edu/scigen/
S.
Yes, that could be a starting point, although the code may not be easy

to edit. In any case, we'd need LyX files, and also tables (perhaps even
equations) that are non-trivial but still syntactically correct.

There are a number of automatic paper generators out there, for different
disciplines (LitCrit, of course, then math, CS, etc). They tend to be
Perl-based (unsurprisingly) and LaTeX-oriented. It seems doable to
repurpose and/or integrate some of them toward LyX. Not sure it's a
GSOC-level project though.

S.

__________________________________________________
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

[Cyrille Artho]

Post by Cyrille Artho
Dear all,
It looks like in the long term, a grammar-based random document
generator for LyX would be very useful for testing. The
"grammar" would
contain rules about how a document looks like: Title, authors,
abstract, sections with subsections and
text/tables/figures/equations.
Tables/figures/equations would again be generated by other rules.
Of course content does not matter, as long as the result is a valid
.lyx file. For testing, the result would be loaded by lyx and saved
again. This would ensure a document does not get corrupted by saving,
no matter how strange it is.
However, it is a significant effort to build a decent document
generator that is useful for such testing... something that
may fit for
GSoC, though. I'll keep this in mind for 2015.
Excellent idea, although the sheer variety of things to test makes the
http://pdos.csail.mit.edu/__scigen/ <http://pdos.csail.mit.edu/scigen/>
S.
Yes, that could be a starting point, although the code may not be easy
to edit. In any case, we'd need LyX files, and also tables (perhaps
even equations) that are non-trivial but still syntactically correct.
There are a number of automatic paper generators out there, for different
disciplines (LitCrit, of course, then math, CS, etc). They tend to be
Perl-based (unsurprisingly) and LaTeX-oriented. It seems doable to
repurpose and/or integrate some of them toward LyX. Not sure it's a
GSOC-level project though.
S.

The size of the project depends a bit on the scope (especially on how
complex the documents/tables should be). We shouldn't forget that the
project needs a good test driver, too, which requires generating the right
LyX user actions to save a previously loaded document, and compares the
outputs. (Maybe it is even possible that the first LyX save has to be
loaded and saved again for the output to be "stable", as a document
generator may produce slightly different files than LyX itself.)

The test driver has to do this many times while catching crashes/timeouts
reliably. So this also takes a few weeks to automate. Add the document
generation itself, and consider everything is done by someone new to the
problem, and it's easy to stretch this to three months, I think.

[stefano franchi]

Post by Cyrille Artho

Post by Cyrille Artho
Dear all,
It looks like in the long term, a grammar-based random document
generator for LyX would be very useful for testing. The
"grammar" would
contain rules about how a document looks like: Title, authors,
abstract, sections with subsections and
text/tables/figures/equations.
Tables/figures/equations would again be generated by other rules.
Of course content does not matter, as long as the result is a valid
.lyx file. For testing, the result would be loaded by lyx and saved
again. This would ensure a document does not get corrupted by
saving,
no matter how strange it is.
However, it is a significant effort to build a decent document
generator that is useful for such testing... something that
may fit for
GSoC, though. I'll keep this in mind for 2015.
Excellent idea, although the sheer variety of things to test makes the
http://pdos.csail.mit.edu/__scigen/ <http://pdos.csail.mit.edu/
scigen/>
S.
Yes, that could be a starting point, although the code may not be easy
to edit. In any case, we'd need LyX files, and also tables (perhaps
even equations) that are non-trivial but still syntactically correct.
There are a number of automatic paper generators out there, for different
disciplines (LitCrit, of course, then math, CS, etc). They tend to be
Perl-based (unsurprisingly) and LaTeX-oriented. It seems doable to
repurpose and/or integrate some of them toward LyX. Not sure it's a
GSOC-level project though.
S.
The size of the project depends a bit on the scope (especially on how

complex the documents/tables should be). We shouldn't forget that the
project needs a good test driver, too, which requires generating the right
LyX user actions to save a previously loaded document, and compares the
outputs. (Maybe it is even possible that the first LyX save has to be
loaded and saved again for the output to be "stable", as a document
generator may produce slightly different files than LyX itself.)
The test driver has to do this many times while catching crashes/timeouts
reliably. So this also takes a few weeks to automate. Add the document
generation itself, and consider everything is done by someone new to the
problem, and it's easy to stretch this to three months, I think.

Oh, you misunderstood me. My guess was it *can't* be done in three months.
Not by an undergraduate-level student, that is.
At any rate, I do agree that it is an idea we should keep present for next
year's GSOC.

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

[Jean-Marc Lasgouttes]

Post by Cyrille Artho
Dear all,
It looks like in the long term, a grammar-based random document
generator for LyX would be very useful for testing. The "grammar" would
contain rules about how a document looks like: Title, authors, abstract,
sections with subsections and text/tables/figures/equations.
Tables/figures/equations would again be generated by other rules.
Of course content does not matter, as long as the result is a valid .lyx
file. For testing, the result would be loaded by lyx and saved again.
This would ensure a document does not get corrupted by saving, no matter
how strange it is.

It can be useful in general, but I doubt that what we are seeing here
corresponds to a well-formed file. There is data corruption of some sort
in memory.

JMarc

[Cyrille Artho]

Post by Jean-Marc Lasgouttes

Post by Cyrille Artho
Dear all,
It looks like in the long term, a grammar-based random document
generator for LyX would be very useful for testing. The "grammar" would
contain rules about how a document looks like: Title, authors, abstract,
sections with subsections and text/tables/figures/equations.
Tables/figures/equations would again be generated by other rules.
Of course content does not matter, as long as the result is a valid .lyx
file. For testing, the result would be loaded by lyx and saved again.
This would ensure a document does not get corrupted by saving, no matter
how strange it is.

It can be useful in general, but I doubt that what we are seeing here
corresponds to a well-formed file. There is data corruption of some sort in
memory.
JMarc

Is it possible for someone to run LyX (compiled with debug information)
within valgrind (http://valgrind.org/)? I guess this requires a powerful
computer. However, it may help a lot as it could show where/how memory gets
corrupted.
Check the home page of valgrind to see which platforms are supported
(basically Linux and not-quite-recent versions of Mac OS):
http://valgrind.org/