Re: bug in cvs
Kornel Benko wrote: > -BEGIN PGP SIGNED MESSAGE- > > On Thursday 16 May 2002 18:53, Herbert Voss wrote: > >>can someone confirm? >> > > No, working here. ok, I see, thanks Herbert -- http://www.lyx.org/help/
Re: bug in cvs
-BEGIN PGP SIGNED MESSAGE- On Thursday 16 May 2002 18:53, Herbert Voss wrote: > can someone confirm? No, working here. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQCVAwUBPOQRZbewfbDGmeqhAQGD0AQAiWs0Vcrb+9Z2qSkkFirMDidcToKfnNyt AkvkZEkPQX8mvpT5f9RViQ+dLY6F6wcbtLTShC/rq9ogBHNbg6UEB0Gph1BlgvC8 ZMOvXgFqPkCQ1qNZVBjkKh5hjx1dSbCMYJYT2QvI+bBKFVM+hmp4GD/xRkE472Gt oUxQrwVAZfo= =6oO2 -END PGP SIGNATURE-
bug in cvs
can someone confirm?
- open new doc
- choose document->class->book(koma class)
- choose document->language->spanish
- write a word
-> dvi-view gives an error
the command
\addto\extrasspanish{\bbl@deactivate{~}}
is unknown
Herbert
--
http://www.lyx.org/help/
Re: bug in cvs
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote: Juergen> Is it possible to add a search path as a LaTeX command to the Juergen> single LaTeX file? So that for example all external filenames Juergen> inside the LaTeX file are without path. >> This is what the \input@path macro does, if I understand correctly >> your question. Juergen> And do we use it? If not why? Is there a drawback using this? Yes, we do use it. It works for all latex macros that honor it, like \includegraphics and \input/include. I think we have everything in place to have things working `just well enough', but this stuff will eventually need a redesign. Unfortunately, I do not have much time to investigate, but I think making it work with insetgraphics is just a few tweaks away. JMarc
Re: bug in cvs
On 10-Apr-2002 Jean-Marc Lasgouttes wrote: > Juergen> Is it possible to add a search path as a LaTeX command to the > Juergen> single LaTeX file? So that for example all external filenames > Juergen> inside the LaTeX file are without path. > > This is what the \input@path macro does, if I understand correctly > your question. And do we use it? If not why? Is there a drawback using this? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ It was a book to kill time for those who liked it better dead.
Re: bug in cvs
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 10-Apr-2002 Jean-Marc Lasgouttes wrote: >>> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: >> Juergen> I think we should generate files always in the tmp dir. We Juergen> never should generate temporary files in another dir (also if Juergen> use_tempdir is false). I understand that someone could wish Juergen> to have all it's LaTeX regarding stuff in one dir and uses Juergen> use_tempdir==false, but generatring temporary files in some Juergen> dir we don't know if we will destroy already existing ones is Juergen> not really nice is it? >> The problem with that is for example if your file is not in the >> docs dir. What name will you give to it? Maybe we should just give >> a unique name like file1234.eps, or something. THen this should >> also be done for include files instead of the current foo/bar.lyx >> => [EMAIL PROTECTED] hack. Or we could use this scheme also for >> insetgraphics. Juergen> Is it possible to add a search path as a LaTeX command to the Juergen> single LaTeX file? So that for example all external filenames Juergen> inside the LaTeX file are without path. This is what the \input@path macro does, if I understand correctly your question. JMarc
Re: bug in cvs
On 10-Apr-2002 Jean-Marc Lasgouttes wrote: >> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: > > Juergen> I think we should generate files always in the tmp dir. We > Juergen> never should generate temporary files in another dir (also if > Juergen> use_tempdir is false). I understand that someone could wish > Juergen> to have all it's LaTeX regarding stuff in one dir and uses > Juergen> use_tempdir==false, but generatring temporary files in some > Juergen> dir we don't know if we will destroy already existing ones is > Juergen> not really nice is it? > > The problem with that is for example if your file is not in the docs > dir. What name will you give to it? Maybe we should just give a unique > name like file1234.eps, or something. THen this should also be done for > include files instead of the current foo/bar.lyx => [EMAIL PROTECTED] hack. > Or we could use this scheme also for insetgraphics. Is it possible to add a search path as a LaTeX command to the single LaTeX file? So that for example all external filenames inside the LaTeX file are without path. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ I have the power to HALT PRODUCTION on all TEENAGE SEX COMEDIES!!
Re: bug in cvs
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> I think we should generate files always in the tmp dir. We Juergen> never should generate temporary files in another dir (also if Juergen> use_tempdir is false). I understand that someone could wish Juergen> to have all it's LaTeX regarding stuff in one dir and uses Juergen> use_tempdir==false, but generatring temporary files in some Juergen> dir we don't know if we will destroy already existing ones is Juergen> not really nice is it? The problem with that is for example if your file is not in the docs dir. What name will you give to it? Maybe we should just give a unique name like file1234.eps, or something. THen this should also be done for include files instead of the current foo/bar.lyx => [EMAIL PROTECTED] hack. Or we could use this scheme also for insetgraphics. JMarc
Re: bug in cvs
On 09-Apr-2002 Jean-Marc Lasgouttes wrote: > Would having prepareFile return RemoveExtension(filename_) fix this? > > Of course the converted files should be generated in /tmp in this > case. However this gives rise to the same complications as in > insetinclude. So this is more work. I think we should generate files always in the tmp dir. We never should generate temporary files in another dir (also if use_tempdir is false). I understand that someone could wish to have all it's LaTeX regarding stuff in one dir and uses use_tempdir==false, but generatring temporary files in some dir we don't know if we will destroy already existing ones is not really nice is it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ To err is human, to repent, divine, to persist, devilish. -- Benjamin Franklin
Re: bug in cvs
Jean-Marc Lasgouttes wrote: > > Herbert> open a new doc and insert a graphic which is two dirs deeper > Herbert> than the doc dir. > > Would having prepareFile return RemoveExtension(filename_) fix this? sure, but only for files which are in deeper dirs. It's no problem for me to change it to an absolute path, but it's a problem if we have 1.2.0 ... and no pres Herbert -- http://www.lyx.org/help/
Re: bug in cvs
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> Jean-Marc Lasgouttes wrote: >>> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> >>> writes: >>> >> But why does latex search in the tmp dir? We give it a nice \input@path to tell that it should also look in the doc dir. Herbert> this belongs to non-(e)ps-files which were converted. >> Could you explain a bit more? Herbert> open a new doc and insert a graphic which is two dirs deeper Herbert> than the doc dir. Would having prepareFile return RemoveExtension(filename_) fix this? Of course the converted files should be generated in /tmp in this case. However this gives rise to the same complications as in insetinclude. So this is more work. JMarc
Re: bug in cvs
Jean-Marc Lasgouttes wrote: >>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> > > Herbert> open a new doc and insert a graphic which is two dirs deeper > Herbert> than the doc dir. > [...] > Herbert> hope, this helps > > I guess it does, but I do not know when I will have time to > investigate this. but remember that this is an important bug! Therefore it seems to be better to make the path absolute, than all works well. Is this not a better solution? But I have no idea about such stuff. http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35468.html Herbert -- http://www.lyx.org/help/
Re: bug in cvs
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> open a new doc and insert a graphic which is two dirs deeper Herbert> than the doc dir. [...] Herbert> hope, this helps I guess it does, but I do not know when I will have time to investigate this. JMarc
Re: bug in cvs
Jean-Marc Lasgouttes wrote: >>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> > >>>But why does latex search in the tmp dir? We give it a nice >>>\input@path to tell that it should also look in the doc dir. >>> > > > Herbert> this belongs to non-(e)ps-files which were converted. > > Could you explain a bit more? open a new doc and insert a graphic which is two dirs deeper than the doc dir. [FormGraphics]out_name: texte/Aufsatz/Digitus/nand-neu.gif Attempting to convert image file: ~/texte/Aufsatz/Digitus/nand-neu.gif [latex]filename = texte/Aufsatz/Digitus/nand-neu.gif Recognised Fileformat: gif decideOutput: lyxrc.pdf_mode = 0 decideOutput: we have PostScript mode tempname = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0/nand-neu.gif buf::tmppath = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0 filename_ = texte/Aufsatz/Digitus/nand-neu.gif outfile_base = /tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0/nand-neu but the temp dir contains only: voss@maria:/tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0> ls -l total 12 -rw-r--r--1 voss users6230 Apr 9 17:58 demo.log -rw-r--r--1 voss users 806 Apr 9 17:58 demo.tex voss@maria:/tmp/lyx_tmpdir26957iLRg9S/lyx_tmpbuf0> cd .. the converted nand-neu.gif is missing. but in the graphics home dir we have the converted one voss@maria:~> ls -l texte/Aufsatz/Digitus/nand* -rw-r--r--1 voss users 24237 Apr 9 17:58 texte/Aufsatz/Digitus/nand-neu.eps <--- !!! -rw---1 voss users1294 May 22 1999 texte/Aufsatz/Digitus/nand-neu.gif hope, this helps Herbert -- http://www.lyx.org/help/
Re: bug in cvs
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> But why does latex search in the tmp dir? We give it a nice >> \input@path to tell that it should also look in the doc dir. Herbert> this belongs to non-(e)ps-files which were converted. Could you explain a bit more? JMarc
Re: bug in cvs
Jean-Marc Lasgouttes wrote: >>"Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: >> > > Herbert> the patch > Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html > > Herbert> is buggy when you insert a graphic file which is in a deeper > Herbert> dir than the one from the doc. In this case the absolut path > Herbert> is missing, the converted image is written into the doc dir > Herbert> and latex fails, because it searchs the image in the temp > Herbert> dir, which is the right place. > > But why does latex search in the tmp dir? We give it a nice > \input@path to tell that it should also look in the doc dir. this belongs to non-(e)ps-files which were converted. HErbert -- http://www.lyx.org/help/
Re: bug in cvs
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> the patch Herbert> http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html Herbert> is buggy when you insert a graphic file which is in a deeper Herbert> dir than the one from the doc. In this case the absolut path Herbert> is missing, the converted image is written into the doc dir Herbert> and latex fails, because it searchs the image in the temp Herbert> dir, which is the right place. But why does latex search in the tmp dir? We give it a nice \input@path to tell that it should also look in the doc dir. JMarc
bug in cvs
the patch http://www.mail-archive.com/lyx-devel%40lists.lyx.org/msg35477.html is buggy when you insert a graphic file which is in a deeper dir than the one from the doc. In this case the absolut path is missing, the converted image is written into the doc dir and latex fails, because it searchs the image in the temp dir, which is the right place. Herbert -- http://www.lyx.org/help/
Re: BUG in cvs
John Levon wrote: > On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote: > > >>- insert float >>- insert into the float a graphic >>- and insert a caption >>- save and close >>- reopen >>---> the caption is outside the float >> > > no, I can't spot any problems like this ... thanks, than it's my own fault. Herbert -- http://www.lyx.org/help/
Re: BUG in cvs
On Sat, Mar 23, 2002 at 06:23:38PM +0100, Herbert Voss wrote: > - insert float > - insert into the float a graphic > - and insert a caption > - save and close > - reopen > ---> the caption is outside the float no, I can't spot any problems like this ... john -- "Way back at the beginning of time around 1970 the first man page was handed down from on high. Every one since is an edited copy." - John Hasler <[EMAIL PROTECTED]>
BUG in cvs
can anybody confirm? - insert float - insert into the float a graphic - and insert a caption - save and close - reopen ---> the caption is outside the float this happens only for graphic insets. Herbert -- http://www.lyx.org/help/
Re: Citations only shown as [?]. Bug in CVS?
On Wed, 13 Feb 2002, R. Lahaye wrote: > R. Lahaye wrote: > > > > the references themselves appear as question-marks in the text [?] > > Sorry, my mistake. I had a look at the LaTeX log file and two equations > were labeled with exactly the same label. For some reason that skrewed > up the referencing table (why?). > > Removing one of the equation labels solved the problem. What may be happening is that LyX sees the error and stops without reporting the error or, more likely, LyX sees that the exit value of latex says somethings wrong but LyX doesn't know what and stays quiet. An extra latex run is what was required but as latex reported an error LyX never makes that extra call. So what we need is for lyx to report the error about multiply defined labels. Allan. (ARRae)
Re: Citations only shown as [?]. Bug in CVS?
R. Lahaye wrote: > > the references themselves appear as question-marks in the text [?] Sorry, my mistake. I had a look at the LaTeX log file and two equations were labeled with exactly the same label. For some reason that skrewed up the referencing table (why?). Removing one of the equation labels solved the problem. Rob.
Re: Citations only shown as [?]. Bug in CVS?
It would seem that another latex run may be needed to fill in the labels. Check the latex log file to see if there are any error messages in the log. Also check to see if a warning line exists that says something like "need another latex run" as this is also used to trigger additional latex runs. Allan. (ARRae)
Citations only shown as [?]. Bug in CVS?
Hi, I am using a bibtex file, which is included at the bottom of the document. All the bibtex-entries appear in the Citation-dialog. There's no problem with the bibtex file, since it works fine with LyX 1.1.6. The cited refs are correctly listed at the end of the paper, but the references themselves appear as question-marks in the text [?] when view DVI or PS. The following "ls -s" is in /tmp (CsSA.lyx is the main lyx file): 3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.aux 3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.bbl 1 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.blg 29 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.dvi 9 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.log 3144 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.ps 21 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex 3 /tmp/lyx_tmpdir99785kY6zWF/lyx_tmpbuf0/CsSA.tex.dep Is this problem due to a bug in CVS, or has something been corrupted at my side? Thanks, Rob.
Re: math bug in cvs
> (if I understands this correctly)... yes why not. > > ...but to avoid rewriting anything in the parser, output it into a > ostringstream and pass that to the parser just as usual. That would be the simple solution. Indeed. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: math bug in cvs
> | reading this formula with 1.2.0 gives always the message > | that the file may be corrupted (truncated). > | so far so good, but lyx ignores all the text behind > | this formula. > > so the formula parser does not read (and remove) the \end_inset... It ignores after its own end everything up to the next \end_inset. I think the only comparatively safe way is to have the lexer reading into a vector up to an \end_inset and let the "real parser" operate on this thing. So an \end_inset cannot be ignored by some wierd structure the parser does not understand... Maybe I should simply do that. Andre' -- André Pönitz . [EMAIL PROTECTED]
Re: math bug in cvs
> sure! but it was lyx which allowed the user to do that!
> and btw: it's no problem to run this with latex! means
> it's allowed latex stuff ...
Ok. I did not know that, so this has to be fixed indeed.
> > It would be pretty difficult to parse bad input, given that it's already a
> > pain to parse correct input...
>
> this is another question. why do you have environments
> \begin_inset TYPE
> \end_inset
>
> when you never stop parsing TYPE with reaching \end_inset???
That's how the outside world does insets. The math parser reads from a $,
\[, \begin{eqnarray} to the corresponding end token. In this case the end
token gets swallowed when the parser tries to read the second but last cell
of the eqnarray which it expects to be terminated by a & and nothing else.
> > It is not. Actually, it does not even fit well into the scheme, since it
> > contains an underscore which is usually not allowed in latex macro names...
>
> I don't know if I understand well: you mean, that all
> lyx1.1.6 and older files can't be read with 1.2.0 when
> they have this little unimportant bug in a formula
I don't know that either ;-)
Andre'
--
André Pönitz . [EMAIL PROTECTED]
Re: math bug in cvs
Andre Poenitz wrote:
>
> > 1.1.6fix3:
> > in an equnarray you can delete the lower right cell.
> > the formula than looks like
> >
> > \begin_inset Formula \begin{eqnarray*}
> > 11 & 21 & 31\\
> > 21 & 22 & 23\\
> > 31 & 32 <- missing cell!
> > \end{eqnarray*}
> >
> > \end_inset
> >
> But that's no well formed LaTeX, even if 1.1.6 allows you to create such
> beasts.
sure! but it was lyx which allowed the user to do that!
and btw: it's no problem to run this with latex! means
it's allowed latex stuff ...
> It would be pretty difficult to parse bad input, given that it's already a
> pain to parse correct input...
this is another question. why do you have environments
\begin_inset TYPE
\end_inset
when you never stop parsing TYPE with reaching \end_inset???
> > I suppose, that "\end_inset" is not a real delimiter
> > for parsing formulas.
>
> It is not. Actually, it does not even fit well into the scheme, since it
> contains an underscore which is usually not allowed in latex macro names...
I don't know if I understand well: you mean, that all
lyx1.1.6 and older files can't be read with 1.2.0 when
they have this little unimportant bug in a formula
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
Re: math bug in cvs
> 1.1.6fix3:
> in an equnarray you can delete the lower right cell.
> the formula than looks like
>
> \begin_inset Formula \begin{eqnarray*}
> 11 & 21 & 31\\
> 21 & 22 & 23\\
> 31 & 32 <- missing cell!
> \end{eqnarray*}
>
> \end_inset
>
> in 1.1.6 this doesn't matter, the lyxfile is always
> read well.
But that's no well formed LaTeX, even if 1.1.6 allows you to create such
beasts.
It would be pretty difficult to parse bad input, given that it's already a
pain to parse correct input...
> I suppose, that "\end_inset" is not a real delimiter
> for parsing formulas.
It is not. Actually, it does not even fit well into the scheme, since it
contains an underscore which is usually not allowed in latex macro names...
Andre'
--
André Pönitz . [EMAIL PROTECTED]
math bug in cvs
1.1.6fix3:
in an equnarray you can delete the lower right cell.
the formula than looks like
\begin_inset Formula \begin{eqnarray*}
11 & 21 & 31\\
21 & 22 & 23\\
31 & 32 <- missing cell!
\end{eqnarray*}
\end_inset
in 1.1.6 this doesn't matter, the lyxfile is always
read well.
reading this formula with 1.2.0 gives always the message
that the file may be corrupted (truncated).
so far so good, but lyx ignores all the text behind
this formula.
I suppose, that "\end_inset" is not a real delimiter
for parsing formulas.
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
Keymap selection [was Re: Bug in CVS]
On Thu, Sep 28, 2000 at 11:40:22PM +0300, Dekel Tsur wrote: > The problem is in Intl::InitKeyMapper: Since the "default" language is > removed, n should be initialized to 0. This reminds me that I plan to add automatic keymap switching according to the current language (this is currently done with Hebrew/English). This means that the old keymap selection dialog should not be ported to the preferences dialog (however, I don't know when I will be able to do this, as I need to finish the export code first. So if porting the dialog isn't very time consuming, it can be done).
Re: Bug in CVS
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> But why sel is 0 ? The problem is in Intl::InitKeyMapper: Since Dekel> the "default" language is removed, n should be initialized to Dekel> 0. I've attached a patch that does both fixes. Applied. JMarc
Re: Bug in CVS
On Thu, Sep 28, 2000 at 05:49:02PM +0200, Lars Gullik Bj&resh;nnes wrote: > | The actual problem is here: > | > | > #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224 > | > | This line should read: > | > | return browser ? fl_get_browser_line(browser, sel) : string(); > | > | instead of: > | > | return browser ? fl_get_browser_line(browser, sel) : 0; > > fixed. > This doesn't solve the problem, as the crash occurs with browser != 0. The problem is that sel = 0, so fl_get_browser_line(browser, sel) returns 0. So the fix should be return (browser && sel > 0) ? fl_get_browser_line(browser, sel) : string(); But why sel is 0 ? The problem is in Intl::InitKeyMapper: Since the "default" language is removed, n should be initialized to 0. I've attached a patch that does both fixes. patch.gz
Re: Bug in CVS
Andre Poenitz <[EMAIL PROTECTED]> writes: | > #3 0x815ec58 in lyx::abort () at abort.C:9 | > #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24 | > ^ This causes | > the crash | | If lyxstring really mimics std::string, the assert is correct: You should | never call a string's constructor on a NULL pointer. I think until a day | or two ago lyxstring behaved wrong by quietly accepting the NULL pointer | and creating an empty string. Correct. | | The actual problem is here: | | > #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224 | | This line should read: | | return browser ? fl_get_browser_line(browser, sel) : string(); | | instead of: | | return browser ? fl_get_browser_line(browser, sel) : 0; fixed. Lgb
Re: Bug in CVS
> #3 0x815ec58 in lyx::abort () at abort.C:9 > #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24 > ^ This causes > the crash If lyxstring really mimics std::string, the assert is correct: You should never call a string's constructor on a NULL pointer. I think until a day or two ago lyxstring behaved wrong by quietly accepting the NULL pointer and creating an empty string. The actual problem is here: > #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224 This line should read: return browser ? fl_get_browser_line(browser, sel) : string(); instead of: return browser ? fl_get_browser_line(browser, sel) : 0; Andre' -- Andre' Poenitz [EMAIL PROTECTED]
Bug in CVS
When \kbmap is true, LyX crashes on startup. This bug is very recent (last day or two). The backtrace: #0 0x401e1a01 in kill () #1 0x401e1863 in gsignal () #2 0x401e28c5 in abort () #3 0x815ec58 in lyx::abort () at abort.C:9 #4 0x8163b0c in lyxstring::lyxstring (this=0xba4c, s=0x0) at LAssert.h:24 ^ This causes the crash #5 0x8088589 in Intl::KeyMapPrim (this=0x81fb8a0) at combox.h:224 #6 0x8088e5e in Intl::Keymap (this=0x81fb8a0, code=23) at intl.C:339 #7 0x8088cf3 in Intl::InitKeyMapper (this=0x81fb8a0, on=true) at intl.C:308 #8 0x80640bf in LyXView::init (this=0x81f3080) at LyXView.C:326 #9 0x8095aa1 in LyXGUI::init (this=0x81d3e40) at lyx_gui.C:251 #10 0x80971c6 in LyX::LyX (this=0xbb40, argc=0xbb60, argv=0xbb74) at ../src/lyx_main.C:105 #11 0x80b5fd6 in main (argc=1, argv=0xbb74) at ../src/main.C:40
Re: Bug in CVS 18/05/00 #2.2
Michael Schmitt <[EMAIL PROTECTED]> writes: | I got another warning when clicking at the end of the loaded document: | | UMR: Uninitialized memory read | This is occurring while in: | int | WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*) | [WorkArea.C:299] Hmm, this is either the X lib or XForms not initializing one or more variables in the event struct. Strange. Lgb | ==
Re: Bug in CVS 18/05/00 #6
Michael Schmitt <[EMAIL PROTECTED]> writes: | UMR: Uninitialized memory read (2 times) | This is occurring while in: | bool MathedXIter::Next() [math_iter.C:632] Ok, should be fixed now. Lgb
Re: Bug in CVS 18/05/00 #5
Michael Schmitt <[EMAIL PROTECTED]> writes: | Hi, | | yet another bug report. Can you have a look at this Jürgen? Lgb
Re: Bug in CVS 18/05/00 #4
Michael Schmitt <[EMAIL PROTECTED]> writes: | I opened a couple of files (it seems like two are not sufficient), made | _no_ changes, then opened one of them again (reloaded). Is this repeatable? And this is the the cvs version, right? | FMR: Free memory read | This is occurring while in: | bool text_fits::operator()(LyXText*&) | [QCfYDL9Ishn54ITXVBUe.o] | __type_0 | std::find_if(__type_0,__type_0,__type_1) | [algorithm] The only reason why this should happen is if there is a text* in the TextCache that is not supposed to be there. (it would point into the void), for the revert/reload I can't see how this can happen, BufferStorage::release should take care of it. What platform was this on? Can this be a platform issue? Jean-Marc, can you see this when you run purify? Lgb
Re: Bug in CVS 18/05/00 #6
Jean-Marc Lasgouttes wrote: > I am looking now for an easy fix. The theory is that, the more purify > warning we shut off, the easier it gets to see the others. Correct! And whenever I get a warning I need to run LyX from scratch again in order to ensure that one report is not caused by a former one. (I.e. the reports you get are the initial ones). Michael -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Re: Bug in CVS 18/05/00 #4
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> I opened a couple of files (it seems like two are not Michael> sufficient), made _no_ changes, then opened one of them again Michael> (reloaded). And if you do make a change, are things different? This is definitely a bug that has been reported earlier and which causes crashes. A must fix. JMarc
Re: Bug in CVS 18/05/00 #6
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> Hi, below please find some reports concerning 'math'
Michael> operations. This will be the last report for today (sigh?). I
Michael> hope you will be able to fix at least some of the 'bugs'. It
Michael> should be fairly easy to fix Uninitialized Memory Reads
Michael> (UMRs). If you think that some of them are corrected, I will
Michael> continue testing.
I think this one comes from the constructor of MathStackXIter:
MathStackXIter(int n = MAX_STACK_ITEMS): imax(n) {
item = new MathedXIter[imax];
i = 0;
}
If I am not mistaken, the contructor of MathedXIter is not called
here. What is the best way to make it happen? I know the proper way is
to use a vector, but an even better way would be to dump the struct
altogether and use an existing STL template.
I am looking now for an easy fix. The theory is that, the more purify
warning we shut off, the easier it gets to see the others.
JMarc
Re: Bug in CVS 18/05/00 #3
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> Hi, when closing LyX the following messages occur all the Michael> time. If I remember correctly, these are well-known messages Michael> which have been considered harmless. I think those problems is in your X libraries. For the record, I do not see them. They might not be harmless, but we cannot do much about them. Note that, since they occur when quitting LyX, there cannot be a lot of problems. JMarc PS: BTW, thanks for all these reports!
Bug in CVS 18/05/00 #6
Hi, below please find some reports concerning 'math' operations. This will be the last report for today (sigh?). I hope you will be able to fix at least some of the 'bugs'. It should be fairly easy to fix Uninitialized Memory Reads (UMRs). If you think that some of them are corrected, I will continue testing. Michael PS: Bug report #4 must be fixed definitively. I got a long sequence of complaints after the one I sent you. UMR: Uninitialized memory read (2 times) This is occurring while in: bool MathedXIter::Next() [math_iter.C:632] bool MathedCursor::Right(bool) [math_cursor.C:285] UpdatableInset::RESULT InsetFormula::LocalDispatch(BufferView*,int,const std::basic_string,std::allocator >&) [formula.C:758] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:578] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:419] C_LyXView_KeyPressMask_raw_callback [LyXView.C:452] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xa71a04 in the heap. Address 0xa71a04 is 172 bytes into a malloc'd block at 0xa71958 of 2824 bytes. This block was allocated from: malloc [rtlib.o] c2n6Fi_Pv_ [libCrun.so.1] void*operator new(unsigned) [rtlib.o] void*operator new[](unsigned) [rtlib.o] MathStackXIter::MathStackXIter(int) [libmathed.a] void __STATIC_CONSTRUCTOR() [libmathed.a] _init [crti.o] _start [crt1.o] UMR: Uninitialized memory read This is occurring while in: bool MathedXIter::Next() [math_iter.C:632] void MathedIter::goPosAbs(int) [math_iter.C:156] void MathedXIter::Merge(LyxArrayBase*) [math_iter.C:508] void MathedCursor::SelPaste() [math_cursor.C:868] UpdatableInset::RESULT InsetFormula::LocalDispatch(BufferView*,int,const std::basic_string,std::allocator >&) [formula.C:843] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:578] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:419] C_LyXView_KeyPressMask_raw_callback [LyXView.C:452] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xa71a5c in the heap. Address 0xa71a5c is 260 bytes into a malloc'd block at 0xa71958 of 2824 bytes. This block was allocated from: malloc [rtlib.o] c2n6Fi_Pv_ [libCrun.so.1] void*operator new(unsigned) [rtlib.o] void*operator new[](unsigned) [rtlib.o] MathStackXIter::MathStackXIter(int) [libmathed.a] void __STATIC_CONSTRUCTOR() [libmathed.a] _init [crti.o] _start [crt1.o] UMR: Uninitialized memory read This is occurring while in: bool MathedXIter::Next() [math_iter.C:602] void MathedXIter::Merge(LyxArrayBase*) [math_iter.C:527] void MathedCursor::SelPaste() [math_cursor.C:868] UpdatableInset::RESULT InsetFormula::LocalDispatch(BufferView*,int,const std::basic_string,std::allocator >&) [formula.C:843] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:578] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:419] C_LyXView_KeyPressMask_raw_callback [LyXView.C:452] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xa71a5c in the heap. Address 0xa71a5c is 260 bytes into a malloc'd block at 0xa71958 of 2824 bytes. This block was allocated from: malloc [rtlib.o] c2n6Fi_Pv_ [libCrun.so.1] void*operator new(unsigned) [rtlib.o] void*operator new[](unsigned) [rtlib.o] MathStackXIter::MathStackXIter(int) [libmathed.a]
Re: Bug in CVS 18/05/00 #4
Michael Schmitt <[EMAIL PROTECTED]> writes: | Hi, | | below please find a severe bug (free memory read with a lot of | operations between free and read operation). | | Michael | | | | I opened a couple of files (it seems like two are not sufficient), made | _no_ changes, then opened one of them again (reloaded). | | | FMR: Free memory read | This is occurring while in: | bool text_fits::operator()(LyXText*&) | [QCfYDL9Ishn54ITXVBUe.o] This looks like the closed buffer (about to be reverted) is not pruned from the TextCache, but it seems a bit strange that this can happen. I will have to look more at this. Lgb
Bug in CVS 18/05/00 #5
Hi,
yet another bug report.
I loaded a file with a figure; minimized the figure ('fig' is printed at
the end of a line); deleted the figure.
The purify reports looks similar to the one that it raised when cutting
a region covering two paragraphs.
Michael
FMR: Free memory read
This is occurring while in:
LyXParagraph*LyXParagraph::Next() [paragraph.C:1197]
void LyXText::CutSelection(bool) [text2.C:2227]
void BufferView::cut() [BufferView2.C:587]
std::basic_string,std::allocator
>LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main [main.C:75]
_start [crt1.o]
Reading 4 bytes from 0x12d87fc in the heap.
Address 0x12d87fc is 196 bytes into a freed block at 0x12d8738 of
260 bytes.
This block was allocated from:
malloc [rtlib.o]
c2n6Fi_Pv_ [libCrun.so.1]
void*operator new(unsigned) [rtlib.o]
void LyXParagraph::BreakParagraphConservative(int)
[paragraph.C:1570]
bool
CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int&,char,bool)
[CutAndPaste.C:96]
void LyXText::CutSelection(bool) [text2.C:2221]
void BufferView::cut() [BufferView2.C:587]
std::basic_string,std::allocator
>LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main [main.C:75]
_start [crt1.o]
There have been 0 frees since this block was freed from:
free [rtlib.o]
c2k6FPv_v_ [libCrun.so.1]
void operator delete(void*) [rtlib.o]
void LyXParagraph::PasteParagraph() [paragraph.C:1624]
bool
CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int&,char,bool)
[CutAndPaste.C:129]
void LyXText::CutSelection(bool) [text2.C:2221]
void BufferView::cut() [BufferView2.C:587]
std::basic_string,std::allocator
>LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main [main.C:75]
_start [crt1.o]
FMR: Free memory read
This is occurring while in:
LyXParagraph*LyXParagraph::Next() [paragraph.C:1197]
void LyXText::CutSelection(bool) [text2.C:2227]
void BufferView::cut() [BufferView2.C:587]
std::basic_string,std::allocator
>LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910]
int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305]
int LyXView::KeyPressMask_raw_callback(forms_*,void*)
[LyXView.C:419]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [libforms.a]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
void LyXGUI::runTime() [lyx_gui.C:621]
LyX::LyX(int*,char**) [lyx_main.C:148]
main [main.C:75]
_start [crt1.o]
Reading 4 bytes from 0x12d87fc in the heap.
Address 0x12d87fc is 196 bytes into a freed block at 0x12d8738 of
260 bytes.
This block was allocated from:
malloc [rtlib.o]
c2n6Fi_Pv_ [libCrun.so.1]
void*operator new(unsigned) [rtlib.o]
void LyXParagraph::BreakParagraphConservative(int)
[paragraph.C:1570]
bool
CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int&,char,bool)
[CutAndPaste.C:96]
void LyXText::CutSelection(bool) [text2.C:2221]
void BufferView::cut() [BufferView2.C:587]
std::basic_string,std::allocator
>LyX
Bug in CVS 18/05/00 #4
Hi, below please find a severe bug (free memory read with a lot of operations between free and read operation). Michael I opened a couple of files (it seems like two are not sufficient), made _no_ changes, then opened one of them again (reloaded). FMR: Free memory read This is occurring while in: bool text_fits::operator()(LyXText*&) [QCfYDL9Ishn54ITXVBUe.o] __type_0 std::find_if(__type_0,__type_0,__type_1) [algorithm] LyXText*TextCache::findFit(Buffer*,unsigned short) [TextCache.C:49] int BufferView::Pimpl::resizeCurrentBuffer() [BufferView_pimpl.C:235] void BufferView::Pimpl::buffer(Buffer*) [BufferView_pimpl.C:133] void BufferView::buffer(Buffer*) [BufferView.C:66] void LyXFunc::MenuOpen() [lyxfunc.C:2820] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:735] void Menus::ShowFileMenu(flobjs_*,long) [menus.C:641] C_Menus_ShowFileMenu [menus.C:71] fl_object_qread [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xbde420 in the heap. Address 0xbde420 is at the beginning of a freed block of 376 bytes. This block was allocated from: malloc [rtlib.o] c2n6Fi_Pv_ [libCrun.so.1] void*operator new(unsigned) [rtlib.o] int BufferView::Pimpl::resizeCurrentBuffer() [BufferView_pimpl.C:246] void BufferView::Pimpl::buffer(Buffer*) [BufferView_pimpl.C:133] void BufferView::buffer(Buffer*) [BufferView.C:66] void LyXFunc::MenuOpen() [lyxfunc.C:2820] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:735] void Menus::ShowFileMenu(flobjs_*,long) [menus.C:641] C_Menus_ShowFileMenu [menus.C:71] fl_object_qread [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] There have been 23967 frees since this block was freed from: free [rtlib.o] c2k6FPv_v_ [libCrun.so.1] void operator delete(void*) [rtlib.o] void delete_text::operator()(LyXText*&) [NVtqvRLYnAsav0BdKzxL.o] __type_1 std::for_each(__type_0,__type_0,__type_1) [algorithm] void TextCache::removeAllWithBuffer(Buffer*) [TextCache.C:137] void BufferStorage::release(Buffer*) [bufferlist.C:59] bool BufferList::close(Buffer*) [bufferlist.C:176] Buffer*BufferList::loadLyXFile(const std::basic_string,std::allocator >&,bool) [bufferlist.C:436] void LyXFunc::MenuOpen() [lyxfunc.C:2818] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:735] void Menus::ShowFileMenu(flobjs_*,long) [menus.C:641] C_Menus_ShowFileMenu [menus.C:71] fl_object_qread [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Bug in CVS 18/05/00 #3
Hi, when closing LyX the following messages occur all the time. If I remember correctly, these are well-known messages which have been considered harmless. Michael FMR: Free memory read This is occurring while in: XDestroyIC [ICWrap.c] void CloseLyXLookup() [lyxlookup.C:207] LyXGUI::~LyXGUI() [lyx_gui.C:205] LyX::~LyX()[lyx_main.C:156] main [main.C:76] _start [crt1.o] Reading 4 bytes from 0x10dc128 in the heap. Address 0x10dc128 is 8 bytes into a freed block at 0x10dc120 of 256 bytes. This block was allocated from: malloc [rtlib.o] _CreateIC [XSunIMIF.c] XCreateIC [ICWrap.c] void InitLyXLookup(_XDisplay*,unsigned long) [lyxlookup.C:56] void LyXView::show(int,int,const char*) [LyXView.C:211] void LyXGUI::create_forms() [lyx_gui.C:596] void LyXGUI::init() [lyx_gui.C:237] LyX::LyX(int*,char**) [lyx_main.C:86] main [main.C:75] _start [crt1.o] There have been 0 frees since this block was freed from: free [rtlib.o] XDestroyIC [ICWrap.c] void CloseLyXLookup() [lyxlookup.C:207] LyXGUI::~LyXGUI() [lyx_gui.C:205] LyX::~LyX()[lyx_main.C:156] main [main.C:76] _start [crt1.o] FUM: Freeing unallocated memory This is occurring while in: free [rtlib.o] void CloseLyXLookup() [lyxlookup.C:207] LyXGUI::~LyXGUI() [lyx_gui.C:205] LyX::~LyX()[lyx_main.C:156] main [main.C:76] _start [crt1.o] Attempting to free block at 0x10dc120 already freed. This block was allocated from: malloc [rtlib.o] _CreateIC [XSunIMIF.c] XCreateIC [ICWrap.c] void InitLyXLookup(_XDisplay*,unsigned long) [lyxlookup.C:56] void LyXView::show(int,int,const char*) [LyXView.C:211] void LyXGUI::create_forms() [lyx_gui.C:596] void LyXGUI::init() [lyx_gui.C:237] LyX::LyX(int*,char**) [lyx_main.C:86] main [main.C:75] _start [crt1.o] There have been 1 frees since this block was freed from: free [rtlib.o] XDestroyIC [ICWrap.c] void CloseLyXLookup() [lyxlookup.C:207] LyXGUI::~LyXGUI() [lyx_gui.C:205] LyX::~LyX()[lyx_main.C:156] main [main.C:76] _start [crt1.o] -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Bug in CVS 18/05/00 #2.2
Michael Schmitt wrote: > Hi, > > importing the ascii file README (from lyx) results in the following > message: I got another warning when clicking at the end of the loaded document: UMR: Uninitialized memory read This is occurring while in: int WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*) [WorkArea.C:299] C_WorkArea_work_area_handler [WorkArea.C:48] fl_handle_it [libforms.a] fl_handle_object [libforms.a] fl_handle_form [libforms.a] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xa1c6fc in the zero'd data, bss section (3 bytes at 0xa1c6fd uninit). Address 0xa1c6fc is 52 bytes past start of global variable "st_xev". This is defined in lyx. -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Bug in CVS 18/05/00 #2
Hi, importing the ascii file README (from lyx) results in the following message: UMR: Uninitialized memory read This is occurring while in: void LyXText::SetSelection() [text2.C:1024] int BufferView::Pimpl::resizeCurrentBuffer() [BufferView_pimpl.C:260] void BufferView::Pimpl::resize() [BufferView_pimpl.C:173] void BufferView::resize() [BufferView.C:78] void Buffer::resize() [bufferlist.o] void BufferList::resize() [bufferlist.C:147] void BufferView::Pimpl::workAreaExpose() [BufferView_pimpl.C:987] void BufferView::workAreaExpose() [BufferView.C:187] int WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*) [WorkArea.C:284] C_WorkArea_work_area_handler [WorkArea.C:48] fl_handle_it [libforms.a] fl_handle_object [libforms.a] redraw_marked [libforms.a] fl_handle_form [libforms.a] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xa8f128 in the heap. Address 0xa8f128 is 240 bytes into a malloc'd block at 0xa8f038 of 376 bytes. This block was allocated from: malloc [rtlib.o] c2n6Fi_Pv_ [libCrun.so.1] void*operator new(unsigned) [rtlib.o] int BufferView::Pimpl::resizeCurrentBuffer() [BufferView_pimpl.C:231] void BufferView::Pimpl::resize() [BufferView_pimpl.C:173] void BufferView::resize() [BufferView.C:78] void Buffer::resize() [bufferlist.o] void BufferList::resize() [bufferlist.C:147] void BufferView::Pimpl::workAreaExpose() [BufferView_pimpl.C:987] void BufferView::workAreaExpose() [BufferView.C:187] int WorkArea::work_area_handler(flobjs_*,int,int,int,int,void*) [WorkArea.C:284] C_WorkArea_work_area_handler [WorkArea.C:48] fl_handle_it [libforms.a] fl_handle_object [libforms.a] redraw_marked [libforms.a] fl_handle_form [libforms.a] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de ==
Bug in CVS 18/05/00 #1
Hi, despite the most recent fixes there is still a problem with cutting a region covering two paragraphs: FMR: Free memory read This is occurring while in: LyXParagraph*LyXParagraph::Next() [paragraph.C:1197] void LyXText::CutSelection(bool) [text2.C:2227] void BufferView::cut() [BufferView2.C:587] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:419] C_LyXView_KeyPressMask_raw_callback [LyXView.C:452] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xcfc97c in the heap. Address 0xcfc97c is 196 bytes into a freed block at 0xcfc8b8 of 260 bytes. This block was allocated from: malloc [rtlib.o] c2n6Fi_Pv_ [libCrun.so.1] void*operator new(unsigned) [rtlib.o] void LyXParagraph::BreakParagraphConservative(int) [paragraph.C:1570] bool CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int&,char,bool) [CutAndPaste.C:96] void LyXText::CutSelection(bool) [text2.C:2221] void BufferView::cut() [BufferView2.C:587] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:419] C_LyXView_KeyPressMask_raw_callback [LyXView.C:452] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] There have been 0 frees since this block was freed from: free [rtlib.o] c2k6FPv_v_ [libCrun.so.1] void operator delete(void*) [rtlib.o] void LyXParagraph::PasteParagraph() [paragraph.C:1624] bool CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int&,char,bool) [CutAndPaste.C:129] void LyXText::CutSelection(bool) [text2.C:2221] void BufferView::cut() [BufferView2.C:587] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:419] C_LyXView_KeyPressMask_raw_callback [LyXView.C:452] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] FMR: Free memory read This is occurring while in: LyXParagraph*LyXParagraph::Next() [paragraph.C:1209] void LyXText::CutSelection(bool) [text2.C:2227] void BufferView::cut() [BufferView2.C:587] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:419] C_LyXView_KeyPressMask_raw_callback [LyXView.C:452] do_interaction_step [libforms.a] fl_treat_interaction_events [libforms.a] fl_check_forms [libforms.a] void LyXGUI::runTime() [lyx_gui.C:621] LyX::LyX(int*,char**) [lyx_main.C:148] main [main.C:75] _start [crt1.o] Reading 4 bytes from 0xcfc97c in the heap. Address 0xcfc97c is 196 bytes into a freed block at 0xcfc8b8 of 260 bytes. This block was allocated from: malloc [rtlib.o] c2n6Fi_Pv_ [libCrun.so.1] void*operator new(unsigned) [rtlib.o] void LyXParagraph::BreakParagraphConservative(int) [paragraph.C:1570] bool CutAndPaste::cutSelection(LyXParagraph*,LyXParagraph**,int,int&,char,bool) [CutAndPaste.C:96] void LyXText::CutSelection(bool) [text2.C:2221] void BufferView::cut() [BufferView2.C:587] std::basic_string,std::allocator >LyXFunc::Dispatch(int,const char*) [lyxfunc.C:910] int LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:305] int LyXView::KeyPressMask_raw_call
Patch (Re: selectlanguage bug in CVS)
On Fri, Apr 07, 2000 at 03:08:32PM +0200, Jean-Marc Lasgouttes wrote: > > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: > Dekel> does not effect the language of the existing text (should it be > Dekel> fixed? namely, after changing the language in the document > Dekel> layout popup, a new yes/no popup appears asking you if you want > Dekel> to change the language of the existing text). > > This should not be a problem. For your changes to be transparent, the > language of any paragraph should be "default", meaning that the > paragraph has the language of the document. It should be set to > "american" or whatever only if the language of the paragraph is > changed _explicitly_. I really prefer this to a popup solution, which > is not really natural IMO. But what if you don't want to change the language of existing text? > I'd like the new language support to be transparent for people who do > not use it. I'm attaching a patch that does the following: When changing the language of the document in the document layout popup, if the document contains only one language, then the language of the existing text is changed into the new document language (otherwise, nothing is done). The patch also contains a rewrite of the Right-to-Left support. The new code is much more cleaner (it is ~100 lines shorter). Note that the file direction.h, so it should be erased from the CVS. patch.gz
Re: selectlanguage bug in CVS
> > Dekel> The correct sequence of actions is to first select the language of the > Dekel> document, and then start writing the text. > > Nice try. Not true. In this example file I explicitly set > the language to english as my first action. Something else > is going wrong. Sorry. I DID fix it. Get the latest CVS version
Re: selectlanguage bug in CVS
On 07-Apr-2000 Jean-Marc Lasgouttes wrote: >> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: > > Dekel> The problem is in the original LyX file: the language of the > Dekel> document is set to English, but the language of each paragraph > Dekel> is American. This happens if you started writing the document, > Dekel> and after writing several paragraphs you changed the language > Dekel> of the document. Currently, the change in the document language > Dekel> does not effect the language of the existing text (should it be > Dekel> fixed? namely, after changing the language in the document > Dekel> layout popup, a new yes/no popup appears asking you if you want > Dekel> to change the language of the existing text). > > This should not be a problem. For your changes to be transparent, the > language of any paragraph should be "default", meaning that the > paragraph has the language of the document. It should be set to > "american" or whatever only if the language of the paragraph is > changed _explicitly_. I really prefer this to a popup solution, which > is not really natural IMO. > > I'd like the new language support to be transparent for people who do > not use it. I second this! And I like the new language support too #:O) As I'm living in a region of Italy where we have to write Italian-German texts ;) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Revolution, n.: A form of government abroad. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: selectlanguage bug in CVS
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> The problem is in the original LyX file: the language of the Dekel> document is set to English, but the language of each paragraph Dekel> is American. This happens if you started writing the document, Dekel> and after writing several paragraphs you changed the language Dekel> of the document. Currently, the change in the document language Dekel> does not effect the language of the existing text (should it be Dekel> fixed? namely, after changing the language in the document Dekel> layout popup, a new yes/no popup appears asking you if you want Dekel> to change the language of the existing text). This should not be a problem. For your changes to be transparent, the language of any paragraph should be "default", meaning that the paragraph has the language of the document. It should be set to "american" or whatever only if the language of the paragraph is changed _explicitly_. I really prefer this to a popup solution, which is not really natural IMO. I'd like the new language support to be transparent for people who do not use it. JMarc
Re: selectlanguage bug in CVS
Dekel> The problem is in the original LyX file: the language of the document is set Dekel> to English, but the language of each paragraph is American. Dekel> This happens if you started writing the document, and after writing several Dekel> paragraphs you changed the language of the document. Currently, the change Dekel> in the document language does not effect the language of the existing text Dekel> (should it be fixed? namely, after changing the language in the document Dekel> layout popup, a new yes/no popup appears asking you if you want to change the Dekel> language of the existing text). I'd second this one. Dekel> The correct sequence of actions is to first select the language of the Dekel> document, and then start writing the text. Nice try. Not true. In this example file I explicitly set the language to english as my first action. Something else is going wrong. Sorry. Dekel> Alternatively, you can always change the language of existing text by Dekel> marking it and then typing M-x language english Temporary fix, but very useful. Thank you. Angus > PS: You should use the latest CVS version (there was a minor bug in the > language support that I've fixed at 2000-04-02). Good to know. If I could log on I would! Angus
Re: selectlanguage bug in CVS
On Fri, Apr 07, 2000 at 09:55:16AM +0100, Angus Leeming wrote:
> When I export a simple document to LaTeX and then
> re-import it into LyX I lose the "Language: english" setting
> in Layout->Document, it being reset to "Language->default".
This is a missing feature in reLyX.
>
> Furthermore, every paragraph is set between \selectlanguage
> markers:
>
> \selectlanguage{american} blah blah blah \selectlanguage{english}
>
The problem is in the original LyX file: the language of the document is set
to English, but the language of each paragraph is American.
This happens if you started writing the document, and after writing several
paragraphs you changed the language of the document. Currently, the change
in the document language does not effect the language of the existing text
(should it be fixed? namely, after changing the language in the document
layout popup, a new yes/no popup appears asking you if you want to change the
language of the existing text).
The correct sequence of actions is to first select the language of the
document, and then start writing the text.
Alternatively, you can always change the language of existing text by
marking it and then typing M-x language english
PS: You should use the latest CVS version (there was a minor bug in the
language support that I've fixed at 2000-04-02).
selectlanguage bug in CVS
When I export a simple document to LaTeX and then
re-import it into LyX I lose the "Language: english" setting
in Layout->Document, it being reset to "Language->default".
Furthermore, every paragraph is set between \selectlanguage
markers:
\selectlanguage{american} blah blah blah \selectlanguage{english}
If this isn't clear enough, I attach a short document
showing it.
Angus
PS. Is it me or is www.lyx.org still unreachable?
A.
#LyX 1.1 created this file. For more info see http://www.lyx.org/
\lyxformat 2.16
\textclass article
\begin_preamble
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{babel}
\makeatletter
\end_preamble
\options american,english
\language default
\inputencoding latin1
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\latex latex
\backslash
selectlanguage{american}
\layout Section
section1
\layout Standard
\latex latex
\backslash
selectlanguage{english}
\layout Standard
\latex latex
\backslash
selectlanguage{american}
\latex default
para1 para1 para1 para1 para1 para1 para1 para1 para1 para1 para1 para1
para1 para1 para1 para1 para1 para1 para1 para1 para1 para1 para1 para1
para1 para1 para1 para1 para1 para1 para1 para1 para1 para1 para1 para1
para1 para1 para1 para1
\latex latex
\backslash
selectlanguage{english}
\layout Standard
\latex latex
\backslash
selectlanguage{american}
\latex default
para2 para2 para2 para2 para2 para2 para2 para2 para2 para2 para2 para2
para2 para2 para2 para2 para2 para2 para2 para2 para2 para2 para2 para2
para2 para2 para2 para2 para2 para2 para2 para2 para2 para2 para2 para2
para2 para2 para2 para2
\latex latex
\backslash
selectlanguage{english}
\layout Standard
\latex latex
\backslash
selectlanguage{american}
\latex default
para3 para3 para3 para3 para3 para3 para3 para3 para3 para3 para3 para3
para3 para3 para3 para3 para3 para3 para3 para3 para3 para3 para3 para3
para3 para3 para3 para3 para3 para3 para3 para3 para3 para3
\latex latex
\backslash
selectlanguage{english}
\layout Standard
\latex latex
\backslash
selectlanguage{american}
\layout Section
section2
\layout Standard
\latex latex
\backslash
selectlanguage{english}
\layout Standard
\latex latex
\backslash
selectlanguage{american}
\latex default
para4 para4 para4 para4 para4 para4 para4 para4 para4 para4 para4 para4
para4 para4 para4 para4 para4 para4 para4 para4 para4 para4 para4 para4
para4 para4
\latex latex
\backslash
selectlanguage{english}
\layout Standard
\latex latex
\backslash
selectlanguage{american}
\latex default
para5 para5 para5 para5 para5 para5 para5 para5 para5 para5 para5 para5
para5 para5 para5 para5 para5 para5 para5 para5 para5 para5 para5 para5
para5 para5 para5 para5 para5 para5 para5 para5 para5 para5 para5
\latex latex
\backslash
selectlanguage{english}
\the_end
Re: Crucial bug in cvs 99/24/01
Michael Schmitt <[EMAIL PROTECTED]> writes: | This is a cryptographically signed message in MIME format. | | --msD1BD4FC02ACFC9AE47A12547 | Content-Type: text/plain; charset=us-ascii | Content-Transfer-Encoding: 7bit | | Hi, | | once again I would like to report a very critical bug in the most | current lyx version. If you view a dvi file and change the text | afterwards, lyx does not allow to update the dvi output later. You need | to restart lyx! | | I looked into my /tmp directory, where lyx writes its output and it | seems like Lyx updates the tex sources correctly. However, it does not | update the dvi file. Could anybody please check why this happens? It | worked very well about two weeks ago. Hence, some code must have been | changed recently. I can not reproduce this. Can you give some more info? lyx -dbg latex is nice... Lgb
Re: Crucial bug in cvs 99/24/01
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> once again I would like to report a very critical bug in the Michael> most current lyx version. If you view a dvi file and change Michael> the text afterwards, lyx does not allow to update the dvi Michael> output later. You need to restart lyx! Michael> I looked into my /tmp directory, where lyx writes its output Michael> and it seems like Lyx updates the tex sources correctly. Michael> However, it does not update the dvi file. Could anybody Michael> please check why this happens? It worked very well about two Michael> weeks ago. Hence, some code must have been changed recently. You should probably post the output of 'lyx -dbg latex' so that Lars can take a look and guess what is wrong. What version of TeX do you use? JMarc
Crucial bug in cvs 99/24/01
Hi, once again I would like to report a very critical bug in the most current lyx version. If you view a dvi file and change the text afterwards, lyx does not allow to update the dvi output later. You need to restart lyx! I looked into my /tmp directory, where lyx writes its output and it seems like Lyx updates the tex sources correctly. However, it does not update the dvi file. Could anybody please check why this happens? It worked very well about two weeks ago. Hence, some code must have been changed recently. Michael -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de == S/MIME Cryptographic Signature
