Re: The LyX licence
Hi, I am the current Danish translator of LyX. I hereby grant permission to licence my contributions to LyX under the Gnu General Public Licence, version 2 or later. Claus Hindsgaul tir, 22 02 2005 kl. 14:55 +, skrev Angus Leeming: Dear all, please excuse the personal email, but I'm trying to do something about the messy state of the LyX licence and need your help. LyX is currently licenced under the GPL with a huge hole blowing it wide apart so that it could be linked against the closed source XForms library. See http://www.lyx.org/about/license.php3. Legal opinion has it that this exception does not apply only to the XForms library. Instead, anything and everything is allowed to link against the LyX source code, defeating the whole point and purpose of the GPL. Moreover, the exception is no longer needed as XForms (and indeed Qt) are available under the GPL. To make a messy situation even messier, it's not even certain whether the current license is valid at all, as the necessary permissions may not have been obtained before the change was made to the original GPL. In light of all this, I'm asking whether I can have your permission to add your names to http://www.lyx.org/blanket-permission.txt: The following people hereby grant permission to licence their contributions to LyX under the Gnu General Public Licence, version 2 or later. so that we can have a permanent record of those people who have contributed code to LyX and who are happy for this code to be licenced under the GPL. Kind regards, Angus ps, if you reply to lyx-devel@lists.lyx.org, we'll have a permanent record of your response. pps. in case you're wondering where I got your email address from: it's listed in the LyX hall of fame: http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/CREDITS?rev=1.53content-type=text/vnd.viewcvs-markup Equivalent URL: http://tinyurl.com/5nqhs -- Ph.D. studerende Claus Hindsgaul Reberbanegade 53, 4. th DK-2300 KBH S
Re: The LyX licence
Hi, I am the current Danish translator of LyX. I hereby grant permission to licence my contributions to LyX under the Gnu General Public Licence, version 2 or later. Claus Hindsgaul tir, 22 02 2005 kl. 14:55 +, skrev Angus Leeming: > Dear all, > > please excuse the personal email, but I'm trying to do something about the > messy state of the LyX licence and need your help. > > LyX is currently licenced under the GPL with a huge hole blowing it wide > apart > so that it could be linked against the closed source XForms library. See > http://www.lyx.org/about/license.php3. Legal opinion has it that this > exception does not apply only to the XForms library. Instead, anything and > everything is allowed to link against the LyX source code, defeating the > whole point and purpose of the GPL. Moreover, the exception is no longer > needed as XForms (and indeed Qt) are available under the GPL. > > To make a messy situation even messier, it's not even certain whether the > current license is valid at all, as the necessary permissions may not have > been obtained before the change was made to the original GPL. > > In light of all this, I'm asking whether I can have your permission to add > your names to http://www.lyx.org/blanket-permission.txt: > > "The following people hereby grant permission to licence their contributions > to LyX under the Gnu General Public Licence, version 2 or later." > > so that we can have a permanent record of those people who have contributed > code to LyX and who are happy for this code to be licenced under the GPL. > > Kind regards, > Angus > > ps, if you reply to lyx-devel@lists.lyx.org, we'll have a permanent record of > your response. > > pps. in case you're wondering where I got your email address from: it's > listed > in the LyX hall of fame: > http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/CREDITS?rev=1.53=text/vnd.viewcvs-markup > Equivalent URL: http://tinyurl.com/5nqhs > -- Ph.D. studerende Claus Hindsgaul Reberbanegade 53, 4. th DK-2300 KBH S
Test of non-member posting
If this gets through, the non-member posting works again. Please disregard this mail. It is only a test. Claus -- Ph.D.-studerende Claus Hindsgaul Reberbanegade 53, 4. th, DK-2300 KBH S Copenhagen, Denmark
Test of non-member posting
If this gets through, the non-member posting works again. Please disregard this mail. It is only a test. Claus -- Ph.D.-studerende Claus Hindsgaul Reberbanegade 53, 4. th, DK-2300 KBH S Copenhagen, Denmark
Re: LaTeX-symbols in XFigs using figtops?
Angus Leeming wrote Hi Claus. Sounds nice indeed! Is there an equivalent fig2pdf script? Yes. The package consist of one perl script (8k) which can produce both ps and/or pdf. It is nice to know that you have worked on similar functionality. I have attached a tarball with the script from the fig2ps Debian package along with its copyright file. Maybe you can get some inspiration for your own scripts or you may find it suitable for inclusion into the LyX codebase? As far as I know it is currently only packaged for Debian. Claus -- Ph.D.-studerende Claus Hindsgaul Reberbanegade 53, 4. th, DK-2300 KBH S Copenhagen, Denmark fig2ps.tar.gz Description: application/compressed-tar
Re: LaTeX-symbols in XFigs using figtops?
Angus Leeming wrote > Hi Claus. > > Sounds nice indeed! Is there an equivalent fig2pdf script? Yes. The package consist of one perl script (8k) which can produce both ps and/or pdf. It is nice to know that you have worked on similar functionality. I have attached a tarball with the script from the fig2ps Debian package along with its copyright file. Maybe you can get some inspiration for your own scripts or you may find it suitable for inclusion into the LyX codebase? As far as I know it is currently only packaged for Debian. Claus -- Ph.D.-studerende Claus Hindsgaul Reberbanegade 53, 4. th, DK-2300 KBH S Copenhagen, Denmark fig2ps.tar.gz Description: application/compressed-tar
LaTeX-symbols in XFigs using figtops?
Hi LyX developers, The package fig2ps in Debian unstable contain a small perl script by Vincent Fourmond, which does excactly what it says. But compared to the fig2dev (used by default by LyX 1.3.3), it lets LaTeX process any text in the figure with the special flag set, so that you can have any LaTeX symbols, formulas etc. in your figure without having to handle split eps and tex file. See: http://packages.debian.org/unstable/tex/fig2ps After having installed it, and simply changing the LyX conversion rule for XFig-eps to invoke figtops --nogv $$i, this is handled transparently to the user if he includes the graphics foo.fig. LyX still displays the figure with LaTeX codes in it, but the final document looks perfect. Since the above package is distributed under the GPL 2 (or later) license, you might want to consider using or including it into LyX? I think the users would love it (At least I would :-) ). Sincerely, Claus Hindgsaul -- Ph.D.-studerende Claus Hindsgaul
LaTeX-symbols in XFigs using figtops?
Hi LyX developers, The package fig2ps in Debian unstable contain a small perl script by Vincent Fourmond, which does excactly what it says. But compared to the fig2dev (used by default by LyX 1.3.3), it lets LaTeX process any text in the figure with the "special" flag set, so that you can have any LaTeX symbols, formulas etc. in your figure without having to handle split eps and tex file. See: http://packages.debian.org/unstable/tex/fig2ps After having installed it, and simply changing the LyX conversion rule for XFig->eps to invoke "figtops --nogv $$i", this is handled transparently to the user if he includes the graphics "foo.fig". LyX still displays the figure with LaTeX codes in it, but the final document looks perfect. Since the above package is distributed under the GPL 2 (or later) license, you might want to consider using or including it into LyX? I think the users would love it (At least I would :-) ). Sincerely, Claus Hindgsaul -- Ph.D.-studerende Claus Hindsgaul
Updated da.po
This is a new updated Danish da.po for LyX 1.3.1pre. Michael Smiths new perl script found a couple of errors, (thanks!) Claus -- Claus Hindsgaul [EMAIL PROTECTED] da.po.gz Description: GNU Zip compressed data
Updated da.po
This is a new updated Danish da.po for LyX 1.3.1pre. Michael Smiths new perl script found a couple of errors, (thanks!) Claus -- Claus Hindsgaul <[EMAIL PROTECTED]> da.po.gz Description: GNU Zip compressed data
Re: Math bug in 1.3.0cvs
fre, 2003-02-07 kl. 09:48 skrev Andre Poenitz: On Thu, Feb 06, 2003 at 04:57:21PM +0100, Claus Hindsgaul wrote: 1. (Optional) Start an empty document 2. Press CTRL-m to start math mode 3. Press CTRL-m to use text font in math mode (\mathrm). No, that starts \textrm. No underscore in \textrm. Type \mathrm if you want \mathrm or bind it to some key (C-m, unfortunately won't be possible). Actually I remembered it wrong (I meant \textrm above). The old LaTeX commands slip my memory after having used LyX for years now :-) That still leaves the reported bug alive in 1.3.0. I think we'll see some chemed in 1.4 if I find the time, which is basically some math inset with some different font handling. That of course would be great for any chemist using LyX! Claus -- Claus Hindsgaul [EMAIL PROTECTED]
Re: Math bug in 1.3.0cvs
fre, 2003-02-07 kl. 10:30 skrev Andre Poenitz: That still leaves the reported bug alive in 1.3.0. Which bug? You can't use '_' in \text*, but \textrm is what 'math text mode' is. OK, but then i believe LyX should not allow you to use it (or possibly print a _ to the screen instead of going into math subscript mode). 1.2.x behaviour was to allow (and handle) subscripts in \textrm mode. My N2 example works fine in 1.2.x but causes errors in 1.3cvs. -- Claus Hindsgaul [EMAIL PROTECTED]
Re: Math bug in 1.3.0cvs
fre, 2003-02-07 kl. 09:48 skrev Andre Poenitz: > On Thu, Feb 06, 2003 at 04:57:21PM +0100, Claus Hindsgaul wrote: > > 1. (Optional) Start an empty document > > 2. Press CTRL-m to start math mode > > 3. Press CTRL-m to use text font in math mode (\mathrm). > > No, that starts \textrm. No underscore in \textrm. > Type \mathrm if you want \mathrm or bind it to some key > (C-m, unfortunately won't be possible). Actually I remembered it wrong (I meant \textrm above). The old LaTeX commands slip my memory after having used LyX for years now :-) That still leaves the reported bug alive in 1.3.0. > I think we'll see some "chemed" in 1.4 if I find the time, which is > basically some math inset with some different font handling. That of course would be great for any chemist using LyX! Claus -- Claus Hindsgaul <[EMAIL PROTECTED]>
Re: Math bug in 1.3.0cvs
fre, 2003-02-07 kl. 10:30 skrev Andre Poenitz: > > That still leaves the reported bug alive in 1.3.0. > > Which bug? You can't use '_' in \text*, but \textrm is what 'math text > mode' is. OK, but then i believe LyX should not allow you to use it (or possibly print a "_" to the screen instead of going into math subscript mode). 1.2.x behaviour was to allow (and handle) subscripts in \textrm mode. My N2 example works fine in 1.2.x but causes errors in 1.3cvs. -- Claus Hindsgaul <[EMAIL PROTECTED]>
Math bug in 1.3.0cvs
Hi, I just stumbled over a math bug trying to write the chemical formula of nitrogen gas (N2). To trigger do the following: 1. (Optional) Start an empty document 2. Press CTRL-m to start math mode 3. Press CTRL-m to use text font in math mode (\mathrm). 4. Write N 5. Press _ for subscript 6. Write 2 7. Now try to compile the document (e.g. show as DVI). 6 errors reportedly due to a misaligned $ Claus Hindsgaul (please cc:)
Math bug in 1.3.0cvs
Hi, I just stumbled over a math bug trying to write the chemical formula of nitrogen gas (N2). To trigger do the following: 1. (Optional) Start an empty document 2. Press CTRL-m to start math mode 3. Press CTRL-m to use text font in math mode (\mathrm). 4. Write "N" 5. Press "_" for subscript 6. Write "2" 7. Now try to compile the document (e.g. show as DVI). 6 errors reportedly due to a misaligned "$" Claus Hindsgaul (please cc:)
da.po update
Another update of da.po for LyX 1.3.0 Claus da.po.gz Description: GNU Zip compressed data
da.po update
Another update of da.po for LyX 1.3.0 Claus da.po.gz Description: GNU Zip compressed data
Updated da.po
Yet another Danish po-update for LyX 1.3.0cvs. Claus -- Claus Hindsgaul [EMAIL PROTECTED] da.po.gz Description: GNU Zip compressed data
Updated da.po
Yet another Danish po-update for LyX 1.3.0cvs. Claus -- Claus Hindsgaul <[EMAIL PROTECTED]> da.po.gz Description: GNU Zip compressed data
da.po for 1.3.0cvs
I have attached an updated da.po for lyx 1.3.0cvs. Sincerely Claus Hindsgaul da.po.gz Description: GNU Zip compressed data
da.po for 1.3.0cvs
I have attached an updated da.po for lyx 1.3.0cvs. Sincerely Claus Hindsgaul da.po.gz Description: GNU Zip compressed data
Updated da.po for 1.3.0cvs
I have attached an updated da.po for LyX 1.3.0cvs. Please insert it into the CVS. Claus -- Claus Hindsgaul [EMAIL PROTECTED] da.po.gz Description: GNU Zip compressed data
Updated da.po for 1.3.0cvs
I have attached an updated da.po for LyX 1.3.0cvs. Please insert it into the CVS. Claus -- Claus Hindsgaul <[EMAIL PROTECTED]> da.po.gz Description: GNU Zip compressed data
Updated da.po for lyx 1.2.2cvs
Hello, I have attached an updated da.po against the lyx-devel lyx-1_2_X branch. Please apply Claus Hindsgaul
Updated da.po for lyx 1.2.2cvs
Hello, I have attached an updated da.po against the lyx-devel lyx-1_2_X branch. Please apply Claus Hindsgaul
Re: Rendering of ^2 and ^3 in 1.2.0
man, 2002-05-27 kl. 16:27 skrev Jean-Marc Lasgouttes: What font encoding do you use? Does it contain these characters? I don't know. I used Encoding: Default in the layout dialog. The problem was fixed with Encoding: Auto. I have been told that these choices mean (not easy to guess from the GUI): Default - TeX default (I don't know where it is set) Auto- Language default (Danish default i.e. ISO8859) Claus Hindsgaul
Re: Rendering of ^2 and ^3 in 1.2.0
man, 2002-05-27 kl. 16:27 skrev Jean-Marc Lasgouttes: > What font encoding do you use? Does it contain these characters? I don't know. I used Encoding: "Default" in the layout dialog. The problem was fixed with Encoding: "Auto". I have been told that these choices mean (not easy to guess from the GUI): "Default" - TeX default (I don't know where it is set) "Auto"- Language default (Danish default i.e. ISO8859) Claus Hindsgaul
Re: contribution: Elsevier preprint class support
matthew arnison wrote: I have made up a basic LyX layout file and template to support the Elsevier preprint class (elsart.cls). They're online at Great, Just what I was looking for! How do you enter more than one author? My best guess (it was yet not documented) was to enter them with lines of the following types Frontmatter TItle Author Author Email Author Author Email Author Author Email Author Homepage Author Address (address of first three authors) Author Author Email Author Address (last author with another affiliation) The footnotes are worked out correctly, but below the title, they appear like: FIRST AUTHOR SECOND AUTHOR THIRD AUTHOR SLANTED ADDRESS FOURTH AUTHOR SLANTED ADDRESS The first three authors should have been on the same line. Was I doing it wrong, or is it a flaw in the class. -- Claus Hindsgaul
Re: contribution: Elsevier preprint class support
matthew arnison wrote: > I have made up a basic LyX layout file and template to support the > Elsevier preprint class (elsart.cls). They're online at Great, Just what I was looking for! How do you enter more than one author? My best guess (it was yet not documented) was to enter them with lines of the following types Frontmatter TItle Author Author Email Author Author Email Author Author Email Author Homepage Author Address (address of first three authors) Author Author Email Author Address (last author with another affiliation) The footnotes are worked out correctly, but below the title, they appear like: The first three authors should have been on the same line. Was I doing it wrong, or is it a flaw in the class. -- Claus Hindsgaul
Rendering of ^2 and ^3 in 1.2.0
Hi, I just found out that on my computer the character ² and ³ (superscript 2 and 3 entered on the keyboard as ^ plus 2 or 3) renders wrongly in the dvi, ps, and pdf output from LyX; they are mangled into two different accented S's. They appear as expected on screen and in the html output though. The workaround is to use math mode. Can anybody confirm this or is it a local problem (e.g. missing fonts) I run LyX 1.2.0cvs on Debian Woody. Claus Hindsgaul
Re: Rendering of ^2 and ^3 in 1.2.0
fre, 2002-05-17 kl. 10:10 skrev Kornel Benko: I just found out that on my computer the character ² and ³ (superscript 2 and 3 entered on the keyboard as ^ plus 2 or 3) renders wrongly in the dvi, ps, and pdf output from LyX; they are mangled into two different accented S's. They appear as expected on screen and in the html output though. Cannot confirm. It is working here. I am using iso8859-15 as screen-fonts. DVI-Output is ok too. (TeX encoding T1) Hmm, I fixed it by going into Document-Layout and choosing encoding auto og latin1 instead of default. What defines my default encoding? As a Dane, I generally use iso8859-1 (Latin1), but something must be wrong. Claus Hindsgaul
RE: Rendering of ^2 and ^3 in 1.2.0
fre, 2002-05-17 kl. 12:58 skrev Juergen Vigna: On 17-May-2002 Claus Hindsgaul wrote: fre, 2002-05-17 kl. 10:56 skrev Juergen Vigna: What screen fonts are you using? What latex encoding are you using? Screen fonts: ISO8859-1 latex: How do I find out? LaTeX most probably has the normal 7bit encoding. But just use auto as default and you'll get the right encoding in most cases :) I don't know where to find the default encoding but I think it's dependant of the .cls file you use. How clever is auto? Would it make a better default for LyX than default? Claus
Re: Rendering of ^2 and ^3 in 1.2.0
Dekel Tsur skrev Fredag den 17. maj 2002 12:28: No, auto select the encoding according to the language of the document (it also allows you to use several encodings in a single document). Wouldn't it give the user (like me) a better clue to rename default to TeX default and auto to Language default. BTW none of these choices are currently translatable. They really should be (so should the units drop box mm, cm, in, ...). Just as you recently did for the country name drop box. Claus
Rendering of ^2 and ^3 in 1.2.0
Hi, I just found out that on my computer the character ² and ³ (superscript 2 and 3 entered on the keyboard as "^" plus "2" or "3") renders wrongly in the dvi, ps, and pdf output from LyX; they are mangled into two different accented "S"'s. They appear as expected on screen and in the html output though. The workaround is to use math mode. Can anybody confirm this or is it a local problem (e.g. missing fonts) I run LyX 1.2.0cvs on Debian Woody. Claus Hindsgaul
Re: Rendering of ^2 and ^3 in 1.2.0
fre, 2002-05-17 kl. 10:10 skrev Kornel Benko: > > I just found out that on my computer the character ² and ³ (superscript > > 2 and 3 entered on the keyboard as "^" plus "2" or "3") renders wrongly > > in the dvi, ps, and pdf output from LyX; they are mangled into two > > different accented "S"'s. > > They appear as expected on screen and in the html output though. > > Cannot confirm. It is working here. I am using iso8859-15 as screen-fonts. > DVI-Output is ok too. (TeX encoding T1) Hmm, I fixed it by going into Document->Layout and choosing encoding "auto" og "latin1" instead of "default". What defines my "default" encoding? As a Dane, I generally use iso8859-1 (Latin1), but something must be wrong. Claus Hindsgaul
RE: Rendering of ^2 and ^3 in 1.2.0
fre, 2002-05-17 kl. 12:58 skrev Juergen Vigna: > > On 17-May-2002 Claus Hindsgaul wrote: > > fre, 2002-05-17 kl. 10:56 skrev Juergen Vigna: > >> What screen fonts are you using? What latex encoding are you using? > > > > Screen fonts: ISO8859-1 > > latex: How do I find out? > > LaTeX most probably has the normal 7bit encoding. But just use > auto as default and you'll get the right encoding in most cases :) > I don't know where to find the default encoding but I think it's > dependant of the .cls file you use. How clever is "auto"? Would it make a better default for LyX than "default"? Claus
Re: Rendering of ^2 and ^3 in 1.2.0
Dekel Tsur skrev Fredag den 17. maj 2002 12:28: > No, auto select the encoding according to the language of the document > (it also allows you to use several encodings in a single document). Wouldn't it give the user (like me) a better clue to rename "default" to "TeX default" and "auto" to "Language default". BTW none of these choices are currently translatable. They really should be (so should the units drop box mm, cm, in, ...). Just as you recently did for the country name drop box. Claus
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-30 kl. 17:47 skrev John Levon: Can you please provide a screenshot. I've tried varying line lengths and am unable to cause any problems Sure. This picture were made after: * Opening LyX * Deactivating Rescale bitmap fonts (so the bug351-file will load) * Opening bug351-2.lyx * Reactivating Rescale bitmap fonts (if this was done from the beginning, the file would'nt load.) I suspect the bug happen as the picture is loaded: First the graphics container adjusts its size to the text: Converting to loadable format..., requiering the line to break. Shortly after the container shrinks to fit the text No file found!, which cause the line to unbreak. LyX does'nt seem to handle this gracefully. Claus bug351.png Description: PNG image
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-30 kl. 17:47 skrev John Levon: > Can you please provide a screenshot. I've tried varying line lengths and > am unable to cause any problems Sure. This picture were made after: * Opening LyX * Deactivating "Rescale bitmap fonts" (so the bug351-file will load) * Opening bug351-2.lyx * Reactivating "Rescale bitmap fonts" (if this was done from the beginning, the file would'nt load.) I suspect the bug happen as the picture is loaded: First the graphics container adjusts its size to the text: "Converting to loadable format...", requiering the line to break. Shortly after the container shrinks to fit the text "No file found!", which cause the line to unbreak. LyX does'nt seem to handle this gracefully. Claus bug351.png Description: PNG image
Re: Language specific crash in LyX 1.2.0cvs
Sorry, no luck with the new patch But I found a very good lead! The problem seems to be tied tightly to the line wrapping on the WYSIWYM screen WHILE LOADING IMAGES. * If I maximize the LyX window before opening the document, the bug can * Choosing Danish language simply change the size of a loading figure by having a different length of displayed status messages. A loading images HAS to be visible on screen while loading to see the bug. Try out the attached minimal offending document. It fails in English now due to a change in line length. Be sure to not maximize your LyX window and deactivate raster font rescaling in LyX in order for the bug to be seen. I use the default LyX windows size. The included image does not have to be included. Claus Hindsgaul #LyX 1.2 created this file. For more info see http://www.lyx.org/ \lyxformat 220 \textclass article \language english \inputencoding default \fontscheme pslatex \graphics default \float_placement htbp \paperfontsize 11 \spacing single \papersize a4paper \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language swedish \quotes_times 2 \papercolumns 2 \papersides 1 \paperpagestyle default \layout Title \size giant Testing lyx bug 351 with a long line \size default \hfill \begin_inset Graphics FormatVersion 1 filename dtupind.eps display grayscale size_type 1 height 2cm keepAspectRatio rotateOrigin center lyxsize_type 1 lyxheight 2cm \end_inset \the_end
Re: Language specific crash in LyX 1.2.0cvs
Sorry, no luck with the new patch But I found a very good lead! The problem seems to be tied tightly to the line wrapping on the WYSIWYM screen WHILE LOADING IMAGES. * If I maximize the LyX window before opening the document, the bug can * Choosing Danish language simply change the size of a loading figure by having a different length of displayed status messages. A loading images HAS to be visible on screen while loading to see the bug. Try out the attached minimal offending document. It fails in English now due to a change in line length. Be sure to not maximize your LyX window and deactivate raster font rescaling in LyX in order for the bug to be seen. I use the default LyX windows size. The included image does not have to be included. Claus Hindsgaul #LyX 1.2 created this file. For more info see http://www.lyx.org/ \lyxformat 220 \textclass article \language english \inputencoding default \fontscheme pslatex \graphics default \float_placement htbp \paperfontsize 11 \spacing single \papersize a4paper \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language swedish \quotes_times 2 \papercolumns 2 \papersides 1 \paperpagestyle default \layout Title \size giant Testing lyx bug 351 with a long line \size default \hfill \begin_inset Graphics FormatVersion 1 filename dtupind.eps display grayscale size_type 1 height 2cm keepAspectRatio rotateOrigin center lyxsize_type 1 lyxheight 2cm \end_inset \the_end
Re: Language specific crash in LyX 1.2.0cvs
man, 2002-04-29 kl. 15:42 skrev Juergen Vigna: Thanks for your backtraces (and patience). Would it be possible for you to apply the attached patch to an updated cvs version and see if that fixes the problem for you? Thank you for the patch. Unfortunately it did not avoid the crash. Would you like a new valgrind log based on the patched, non optimized lyx? Claus Hindsgaul
Re: Language specific crash in LyX 1.2.0cvs
By request, I have obtained the following backtraces from valgrind
(attached) and gdb from a LyX 1.2.0CVS of today with Juergens patch
applied compiled with --disable-optimization. They were both made doing
the same thing as in my prior backtraces.
Claus Hindsgaul
gdb:
(gdb) run
Starting program: /usr/local/bin/lyx
Program received signal SIGSEGV, Segmentation fault.
Row::par (this=0x18) at lyxrow.h:92
92 return par_;
(gdb) backtrace
#0 Row::par (this=0x18) at lyxrow.h:92
#1 0x08132c65 in LyXText::drawInset (this=0x83e0d58, p=@0xb000, pos=20) at
text.C:495
#2 0x08133707 in LyXText::draw (this=0x83e0d58, p=@0xb000, vpos=@0xbfffefb8) at
text.C:649
#3 0x08141fac in LyXText::paintRowText (this=0x83e0d58, p=@0xb000) at text.C:3665
#4 0x081421ed in LyXText::getVisibleRow (this=0x83e0d58, bv=0x83cb430, y_offset=56,
x_offset=0, row=0x83e11d0, y=56,
cleared=false) at text.C:3723
#5 0x0811c4bd in LyXScreen::drawFromTo (this=0x841b630, text=0x83e0d58, bv=0x83cb430,
y1=0, y2=414, y_offset=0, x_offset=0,
internal=true) at screen.C:130
#6 0x0811c33d in LyXScreen::redraw (this=0x841b630, text=0x83e0d58, bv=0x83cb430) at
screen.C:92
#7 0x0805d77a in BufferView::Pimpl::workAreaExpose (this=0x83cb580) at
BufferView_pimpl.C:1073
#8 0x0806b389 in SigC::ObjectSlot0_void, BufferView::Pimpl::callback (d=0x83cc2b4)
at ../sigc++/object_slot.h:56
#9 0x08058823 in SigC::Callback0void::call (this=0x83cc2b4) at
../../sigc++/slot.h:260
#10 0x0805890b in SigC::Signal0void, SigC::Marshalvoid ::emit (this=0x83cb5ac) at
../../sigc++/basic_signal.h:194
#11 0x080596b3 in SigC::Signal0void, SigC::Marshalvoid ::operator()
(this=0x83cb5ac) at ../../../sigc++/basic_signal.h:172
#12 0x080a15aa in WorkArea::work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:352
#13 0x080a05fe in C_WorkArea_work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:68
#14 0x400828f3 in fl_reset_focus_object () from /usr/X11R6/lib/libforms.so.0.89
#15 0x400829b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#16 0x400822c8 in fl_find_last () from /usr/X11R6/lib/libforms.so.0.89
#17 0x4008241e in fl_redraw_form () from /usr/X11R6/lib/libforms.so.0.89
#18 0x40081a45 in fl_hide_object () from /usr/X11R6/lib/libforms.so.0.89
#19 0x080a1168 in {anonymous}::destroy_object (obj=0x83cb858) at WorkArea.C:239
#20 0x080a11b1 in WorkArea::createPixmap (this=0x83cb5ac, width=667, height=414) at
WorkArea.C:253
#21 0x080a159b in WorkArea::work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:351
#22 0x080a05fe in C_WorkArea_work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:68
#23 0x400828f3 in fl_reset_focus_object () from /usr/X11R6/lib/libforms.so.0.89
#24 0x400829b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#25 0x400822c8 in fl_find_last () from /usr/X11R6/lib/libforms.so.0.89
#26 0x400823cb in fl_redraw_object () from /usr/X11R6/lib/libforms.so.0.89
#27 0x080a2396 in WorkArea::redraw (this=0x83cb5ac) at WorkArea.h:53
#28 0x0805aea2 in BufferView::Pimpl::redraw (this=0x83cb580) at BufferView_pimpl.C:270
#29 0x0805b5d2 in BufferView::Pimpl::resizeCurrentBuffer (this=0x83cb580) at
BufferView_pimpl.C:385
#30 0x0805ac15 in BufferView::Pimpl::buffer (this=0x83cb580, b=0x83e0ae0) at
BufferView_pimpl.C:214
#31 0x08054006 in BufferView::buffer (this=0x83cb430, b=0x83e0ae0) at BufferView.C:64
#32 0x080f2cdf in LyXFunc::open (this=0x83b4b30, fname=@0xba20) at lyxfunc.C:1905
#33 0x080efd03 in LyXFunc::dispatch (this=0x83b4b30, action=LFUN_FILE_OPEN,
argument=0xba20) at lyxfunc.C:1346
#34 0x080ed78a in LyXFunc::verboseDispatch (this=0x83b4b30, action=LFUN_FILE_OPEN,
argument=@0xba54, show_sc=true)
at lyxfunc.C:803
#35 0x080ed734 in LyXFunc::verboseDispatch (this=0x83b4b30, ac=461, show_sc=true) at
lyxfunc.C:795
#36 0x0824b083 in Menubar::Pimpl::MenuCallback (ob=0x83c5000, button=1) at
Menubar_pimpl.C:586
#37 0x08248b96 in C_Menubar_Pimpl_MenuCallback (ob=0x83c5000, button=1) at
Menubar_pimpl.C:80
#38 0x40047cb4 in fl_object_qread () from /usr/X11R6/lib/libforms.so.0.89
#39 0x40058679 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#40 0x08247c7a in GUIRunTime::runTime () at GUIRunTime.C:94
#41 0x080e08ab in LyXGUI::runTime (this=0x835a4f8) at lyx_gui.C:292
#42 0x080e10b5 in LyX::LyX (this=0xbc0c, argc=0xbc34, argv=0xbc94) at
../src/lyx_main.C:176
#43 0x0810d40e in main (argc=1, argv=0xbc94) at ../src/main.C:38
(gdb)
==18461== valgrind-20020424, a memory error detector for x86 GNU/Linux.
==18461== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==18461== Estimated CPU clock rate is 199 MHz
==18461== For more details, rerun with: -v
==18461==
--18461-- Warning: splitting giant basic block into pieces
--18461-- Warning: splitting giant basic block into pieces
--18461-- Warning: splitting giant basic block into pieces
--18461-- Warning: splitting giant basic block
Re: Language specific crash in LyX 1.2.0cvs
man, 2002-04-29 kl. 15:42 skrev Juergen Vigna: > Thanks for your backtraces (and patience). Would it be possible for you to > apply the attached patch to an updated cvs version and see if that fixes the > problem for you? Thank you for the patch. Unfortunately it did not avoid the crash. Would you like a new valgrind log based on the patched, non optimized lyx? Claus Hindsgaul
Re: Language specific crash in LyX 1.2.0cvs
By request, I have obtained the following backtraces from valgrind
(attached) and gdb from a LyX 1.2.0CVS of today with Juergens patch
applied compiled with --disable-optimization. They were both made doing
the same thing as in my prior backtraces.
Claus Hindsgaul
gdb:
(gdb) run
Starting program: /usr/local/bin/lyx
Program received signal SIGSEGV, Segmentation fault.
Row::par (this=0x18) at lyxrow.h:92
92 return par_;
(gdb) backtrace
#0 Row::par (this=0x18) at lyxrow.h:92
#1 0x08132c65 in LyXText::drawInset (this=0x83e0d58, p=@0xb000, pos=20) at
text.C:495
#2 0x08133707 in LyXText::draw (this=0x83e0d58, p=@0xb000, vpos=@0xbfffefb8) at
text.C:649
#3 0x08141fac in LyXText::paintRowText (this=0x83e0d58, p=@0xb000) at text.C:3665
#4 0x081421ed in LyXText::getVisibleRow (this=0x83e0d58, bv=0x83cb430, y_offset=56,
x_offset=0, row=0x83e11d0, y=56,
cleared=false) at text.C:3723
#5 0x0811c4bd in LyXScreen::drawFromTo (this=0x841b630, text=0x83e0d58, bv=0x83cb430,
y1=0, y2=414, y_offset=0, x_offset=0,
internal=true) at screen.C:130
#6 0x0811c33d in LyXScreen::redraw (this=0x841b630, text=0x83e0d58, bv=0x83cb430) at
screen.C:92
#7 0x0805d77a in BufferView::Pimpl::workAreaExpose (this=0x83cb580) at
BufferView_pimpl.C:1073
#8 0x0806b389 in SigC::ObjectSlot0_<void, BufferView::Pimpl>::callback (d=0x83cc2b4)
at ../sigc++/object_slot.h:56
#9 0x08058823 in SigC::Callback0::call (this=0x83cc2b4) at
../../sigc++/slot.h:260
#10 0x0805890b in SigC::Signal0<void, SigC::Marshal >::emit (this=0x83cb5ac) at
../../sigc++/basic_signal.h:194
#11 0x080596b3 in SigC::Signal0<void, SigC::Marshal >::operator()
(this=0x83cb5ac) at ../../../sigc++/basic_signal.h:172
#12 0x080a15aa in WorkArea::work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:352
#13 0x080a05fe in C_WorkArea_work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:68
#14 0x400828f3 in fl_reset_focus_object () from /usr/X11R6/lib/libforms.so.0.89
#15 0x400829b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#16 0x400822c8 in fl_find_last () from /usr/X11R6/lib/libforms.so.0.89
#17 0x4008241e in fl_redraw_form () from /usr/X11R6/lib/libforms.so.0.89
#18 0x40081a45 in fl_hide_object () from /usr/X11R6/lib/libforms.so.0.89
#19 0x080a1168 in {anonymous}::destroy_object (obj=0x83cb858) at WorkArea.C:239
#20 0x080a11b1 in WorkArea::createPixmap (this=0x83cb5ac, width=667, height=414) at
WorkArea.C:253
#21 0x080a159b in WorkArea::work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:351
#22 0x080a05fe in C_WorkArea_work_area_handler (ob=0x83cc3e8, event=1, key=0, xev=0x0)
at WorkArea.C:68
#23 0x400828f3 in fl_reset_focus_object () from /usr/X11R6/lib/libforms.so.0.89
#24 0x400829b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#25 0x400822c8 in fl_find_last () from /usr/X11R6/lib/libforms.so.0.89
#26 0x400823cb in fl_redraw_object () from /usr/X11R6/lib/libforms.so.0.89
#27 0x080a2396 in WorkArea::redraw (this=0x83cb5ac) at WorkArea.h:53
#28 0x0805aea2 in BufferView::Pimpl::redraw (this=0x83cb580) at BufferView_pimpl.C:270
#29 0x0805b5d2 in BufferView::Pimpl::resizeCurrentBuffer (this=0x83cb580) at
BufferView_pimpl.C:385
#30 0x0805ac15 in BufferView::Pimpl::buffer (this=0x83cb580, b=0x83e0ae0) at
BufferView_pimpl.C:214
#31 0x08054006 in BufferView::buffer (this=0x83cb430, b=0x83e0ae0) at BufferView.C:64
#32 0x080f2cdf in LyXFunc::open (this=0x83b4b30, fname=@0xba20) at lyxfunc.C:1905
#33 0x080efd03 in LyXFunc::dispatch (this=0x83b4b30, action=LFUN_FILE_OPEN,
argument=0xba20) at lyxfunc.C:1346
#34 0x080ed78a in LyXFunc::verboseDispatch (this=0x83b4b30, action=LFUN_FILE_OPEN,
argument=@0xba54, show_sc=true)
at lyxfunc.C:803
#35 0x080ed734 in LyXFunc::verboseDispatch (this=0x83b4b30, ac=461, show_sc=true) at
lyxfunc.C:795
#36 0x0824b083 in Menubar::Pimpl::MenuCallback (ob=0x83c5000, button=1) at
Menubar_pimpl.C:586
#37 0x08248b96 in C_Menubar_Pimpl_MenuCallback (ob=0x83c5000, button=1) at
Menubar_pimpl.C:80
#38 0x40047cb4 in fl_object_qread () from /usr/X11R6/lib/libforms.so.0.89
#39 0x40058679 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#40 0x08247c7a in GUIRunTime::runTime () at GUIRunTime.C:94
#41 0x080e08ab in LyXGUI::runTime (this=0x835a4f8) at lyx_gui.C:292
#42 0x080e10b5 in LyX::LyX (this=0xbc0c, argc=0xbc34, argv=0xbc94) at
../src/lyx_main.C:176
#43 0x0810d40e in main (argc=1, argv=0xbc94) at ../src/main.C:38
(gdb)
==18461== valgrind-20020424, a memory error detector for x86 GNU/Linux.
==18461== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==18461== Estimated CPU clock rate is 199 MHz
==18461== For more details, rerun with: -v
==18461==
--18461-- Warning: splitting giant basic block into pieces
--18461-- Warning: splitting giant basic block into pieces
--18461-- Warning: splitting giant basic block into pieces
--18461-- Warning: splitting
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-23 kl. 14:10 skrev Juergen Vigna: Sorry again what version of LyX are you using? Are you using the current cvs tree? I seem to see differences in the backtraces valgrind gives and the sourcecode (for example there is no row-previous() in draw!). I have now deleted and checked out lyx-devel again from the CVS of today, rebuilt and produced a new lyxlog.txt the same way (yes, the bug is still there). The version of valgrind is printed in the header of the log-file. Did that help? Claus ==5472== valgrind-20020422, a memory error detector for x86 GNU/Linux. ==5472== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==5472== For more details, rerun with: -v ==5472== --5472-- Warning: splitting giant basic block into pieces --5472-- Warning: splitting giant basic block into pieces --5472-- Warning: splitting giant basic block into pieces --5472-- Warning: splitting giant basic block into pieces ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4000CFBC: strchr (in /lib/ld-2.2.5.so) ==5472==by 0x40655A2A: (within /lib/libc-2.2.5.so) ==5472==by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so) ==5472==by 0x40655E67: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4000CFCC: strchr (in /lib/ld-2.2.5.so) ==5472==by 0x40655A2A: (within /lib/libc-2.2.5.so) ==5472==by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so) ==5472==by 0x40655E67: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4000CFDA: strchr (in /lib/ld-2.2.5.so) ==5472==by 0x40655A2A: (within /lib/libc-2.2.5.so) ==5472==by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so) ==5472==by 0x40655E67: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4B1C: (within /lib/libc-2.2.5.so) ==5472==by 0x4063E386: (within /lib/libc-2.2.5.so) ==5472==by 0x4063DDB9: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4B2C: (within /lib/libc-2.2.5.so) ==5472==by 0x4063E386: (within /lib/libc-2.2.5.so) ==5472==by 0x4063DDB9: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A40: (within /lib/libc-2.2.5.so) ==5472==by 0x426D85F2: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A59: (within /lib/libc-2.2.5.so) ==5472==by 0x426D85F2: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A27: (within /lib/libc-2.2.5.so) ==5472==by 0x426D893B: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A35: (within /lib/libc-2.2.5.so) ==5472==by 0x426D893B: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Syscall param socketcall.connect(serv_addr) contains uninitialised or unaddressable byte(s) ==5472==at 0x4062F712: (within /lib/libc-2.2.5.so) ==5472==by 0x40467DBF: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x40431926: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==Address 0xB630 is not stack'd, malloc'd or free'd ==5472== ==5472== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==5472==at 0x40622414: (within /lib/libc-2.2.5.so) ==5472==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==Address 0x424BB53A is 938 bytes inside a block of size 2048 alloc'd ==5472==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==5472==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==5472== ==5472== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==5472==at 0x40622414: (within /lib/libc-2.2.5.so) ==5472==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==Address 0x424BB53A is 938 bytes inside a block of size 2048 alloc'd ==5472==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==5472==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4031D8A2: (within /usr/X11R6/lib/libforms.so.0.89) ==5472==by 0x4031DFDB: (within
Re: Language specific crash in LyX 1.2.0cvs
ons, 2002-04-24 kl. 15:27 skrev John Levon: Did that help? No ! Look at the backtrace yourself then look at the source they are completely different. Perhaps a valgrind bug ? Or perhaps an optimized executable... I have recompiled LyX without optimizations, deleting all -O options in the configure file (since 'configure --disable-optimizations' did not seem to do what it is supposed to do!) I think the new valgrind output looks more sane (attached) BTW my systems are Debian Woody (yes, the bug is on both systems) and LyX configure summarizes one as: Configuration Host type: i686-pc-linux-gnu Special build flags:included-libsigc xforms-image-loader C Compiler: gcc C Compiler flags: -g C++ Compiler: g++ (2.95.4) C++ Compiler flags: -g -fno-exceptions Linker flags: Frontend: xforms libXpm version: 4.11 libforms version: 0.89.5 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx Claus ==20545== valgrind-20020424, a memory error detector for x86 GNU/Linux. ==20545== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==20545== Estimated CPU clock rate is 199 MHz ==20545== For more details, rerun with: -v ==20545== --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces ==20545== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==20545==at 0x40625414: (within /lib/libc-2.2.5.so) ==20545==by 0x4046AE83: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4044F9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==Address 0x4243D6D6 is 938 bytes inside a block of size 2048 alloc'd ==20545==at 0x4003D43C: calloc (vg_clientfuncs.c:202) ==20545==by 0x40443236: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4031A009: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) ==20545==at 0x4062C2B7: (within /lib/libc-2.2.5.so) ==20545==by 0x4046A3C3: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4046AEDB: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==Address 0x4297FB8A is 850 bytes inside a block of size 247080 alloc'd ==20545==at 0x4003D018: malloc (vg_clientfuncs.c:96) ==20545==by 0x40452AB5: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4044706D: (within /usr/X11R6/lib/libX11.so.6.2) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208A2: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208B1: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208B9: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208C1: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208C9: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208D9: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) convert: /usr/local/lib/valgrind/libpthread.so.0: no version information available (required by /usr/lib/libMagick.so.5) convert: /usr/local/lib/valgrind/libpthread.so.0: no version information available (required by /usr/lib/libMagick.so.5) ==20545== ==20545==
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-23 kl. 14:10 skrev Juergen Vigna: > Sorry again what version of LyX are you using? Are you using the current > cvs tree? I seem to see differences in the backtraces valgrind gives and > the sourcecode (for example there is no row->previous() in draw!). I have now deleted and checked out lyx-devel again from the CVS of today, rebuilt and produced a new lyxlog.txt the same way (yes, the bug is still there). The version of valgrind is printed in the header of the log-file. Did that help? Claus ==5472== valgrind-20020422, a memory error detector for x86 GNU/Linux. ==5472== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==5472== For more details, rerun with: -v ==5472== --5472-- Warning: splitting giant basic block into pieces --5472-- Warning: splitting giant basic block into pieces --5472-- Warning: splitting giant basic block into pieces --5472-- Warning: splitting giant basic block into pieces ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4000CFBC: strchr (in /lib/ld-2.2.5.so) ==5472==by 0x40655A2A: (within /lib/libc-2.2.5.so) ==5472==by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so) ==5472==by 0x40655E67: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4000CFCC: strchr (in /lib/ld-2.2.5.so) ==5472==by 0x40655A2A: (within /lib/libc-2.2.5.so) ==5472==by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so) ==5472==by 0x40655E67: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4000CFDA: strchr (in /lib/ld-2.2.5.so) ==5472==by 0x40655A2A: (within /lib/libc-2.2.5.so) ==5472==by 0x40009ACB: _dl_catch_error (in /lib/ld-2.2.5.so) ==5472==by 0x40655E67: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4B1C: (within /lib/libc-2.2.5.so) ==5472==by 0x4063E386: (within /lib/libc-2.2.5.so) ==5472==by 0x4063DDB9: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4B2C: (within /lib/libc-2.2.5.so) ==5472==by 0x4063E386: (within /lib/libc-2.2.5.so) ==5472==by 0x4063DDB9: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A40: (within /lib/libc-2.2.5.so) ==5472==by 0x426D85F2: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A59: (within /lib/libc-2.2.5.so) ==5472==by 0x426D85F2: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A27: (within /lib/libc-2.2.5.so) ==5472==by 0x426D893B: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x405D4A35: (within /lib/libc-2.2.5.so) ==5472==by 0x426D893B: (within /lib/libnss_files-2.2.5.so) ==5472==by 0x4063E3DB: (within /lib/libc-2.2.5.so) ==5472== ==5472== Syscall param socketcall.connect(serv_addr) contains uninitialised or unaddressable byte(s) ==5472==at 0x4062F712: (within /lib/libc-2.2.5.so) ==5472==by 0x40467DBF: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x40431926: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==Address 0xB630 is not stack'd, malloc'd or free'd ==5472== ==5472== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==5472==at 0x40622414: (within /lib/libc-2.2.5.so) ==5472==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==Address 0x424BB53A is 938 bytes inside a block of size 2048 alloc'd ==5472==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==5472==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==5472== ==5472== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==5472==at 0x40622414: (within /lib/libc-2.2.5.so) ==5472==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==Address 0x424BB53A is 938 bytes inside a block of size 2048 alloc'd ==5472==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==5472==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==5472==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==5472== ==5472== Conditional jump or move depends on uninitialised value(s) ==5472==at 0x4031D8A2: (within /usr/X11R6/lib/libforms.so.0.89) ==5472==by 0x4031DFDB: (within
Re: Language specific crash in LyX 1.2.0cvs
ons, 2002-04-24 kl. 15:27 skrev John Levon: > > Did that help? > > No ! Look at the backtrace yourself then look at the source they are > completely different. Perhaps a valgrind bug ? Or perhaps an optimized executable... I have recompiled LyX without optimizations, deleting all "-O" options in the configure file (since 'configure --disable-optimizations' did not seem to do what it is supposed to do!) I think the new valgrind output looks more sane (attached) BTW my systems are Debian Woody (yes, the bug is on both systems) and LyX configure summarizes one as: Configuration Host type: i686-pc-linux-gnu Special build flags:included-libsigc xforms-image-loader C Compiler: gcc C Compiler flags: -g C++ Compiler: g++ (2.95.4) C++ Compiler flags: -g -fno-exceptions Linker flags: Frontend: xforms libXpm version: 4.11 libforms version: 0.89.5 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx Claus ==20545== valgrind-20020424, a memory error detector for x86 GNU/Linux. ==20545== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==20545== Estimated CPU clock rate is 199 MHz ==20545== For more details, rerun with: -v ==20545== --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces --20545-- Warning: splitting giant basic block into pieces ==20545== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==20545==at 0x40625414: (within /lib/libc-2.2.5.so) ==20545==by 0x4046AE83: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4044F9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==Address 0x4243D6D6 is 938 bytes inside a block of size 2048 alloc'd ==20545==at 0x4003D43C: calloc (vg_clientfuncs.c:202) ==20545==by 0x40443236: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4031A009: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s) ==20545==at 0x4062C2B7: (within /lib/libc-2.2.5.so) ==20545==by 0x4046A3C3: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4046AEDB: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==Address 0x4297FB8A is 850 bytes inside a block of size 247080 alloc'd ==20545==at 0x4003D018: malloc (vg_clientfuncs.c:96) ==20545==by 0x40452AB5: (within /usr/X11R6/lib/libX11.so.6.2) ==20545==by 0x4044706D: (within /usr/X11R6/lib/libX11.so.6.2) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208A2: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208B1: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208B9: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208C1: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208C9: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) ==20545== ==20545== Conditional jump or move depends on uninitialised value(s) ==20545==at 0x403208D9: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40320FDB: (within /usr/X11R6/lib/libforms.so.0.89) ==20545==by 0x40321649: (within /usr/X11R6/lib/libforms.so.0.89) convert: /usr/local/lib/valgrind/libpthread.so.0: no version information available (required by /usr/lib/libMagick.so.5) convert: /usr/local/lib/valgrind/libpthread.so.0: no version information available (required by /usr/lib/libMagick.so.5) ==20545==
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-23 kl. 11:18 skrev Jean-Marc Lasgouttes: If you have time, you may want to try our valgrind http://developer.kde.org/~sewardj/ I tried it by simply invoking 'valgrind lyx'. The crash did NOT happen within valgrind, but a lot of messages were output at the expected time of the crash. I have attached the output for the two cases excactly as described in my earlier posting: * lyxlog.txt: With the crash messages (but no actual crash within valgrind), LC_ALL=da_DK, scalable fonts option DEACTIVATED * lyxlog_ok.txt: No crash, LC_ALL=da_DK, but the scalable fonts option ACTIVATED Claus Hindsgaul ==30304== valgrind-20020422, a memory error detector for x86 GNU/Linux. ==30304== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==30304== For more details, rerun with: -v ==30304== --30304-- Warning: splitting giant basic block into pieces --30304-- Warning: splitting giant basic block into pieces --30304-- Warning: splitting giant basic block into pieces --30304-- Warning: splitting giant basic block into pieces ==30304== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==30304==at 0x40622414: (within /lib/libc-2.2.5.so) ==30304==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==30304==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==30304==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==30304== ==30304== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==30304==at 0x40622414: (within /lib/libc-2.2.5.so) ==30304==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==30304==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==30304==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==30304== ==30304== Invalid read of size 4 ==30304==at 0x8139486: Row::previous(void) const (lyxrow.C:112) ==30304==by 0x816E337: LyXText::draw(LyXText::DrawRowParams , int ) (text.C:650) ==30304==by 0x8179678: LyXText::paintRowText(LyXText::DrawRowParams ) (text.C:3665) ==30304==by 0x8179800: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==30304==Address 0x42D564F4 is 32 bytes inside a block of size 36 free'd ==30304==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==30304==by 0x817ADBE: LyXText::removeRow(Row *) const (text2.C:377) ==30304==by 0x8171753: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==30304==by 0x8181124: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==30304== ==30304== Invalid read of size 4 ==30304==at 0x816D9B3: LyXText::drawInset(LyXText::DrawRowParams , int) (lyxrow.h:91) ==30304==by 0x816E337: LyXText::draw(LyXText::DrawRowParams , int ) (text.C:650) ==30304==by 0x8179678: LyXText::paintRowText(LyXText::DrawRowParams ) (text.C:3665) ==30304==by 0x8179800: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==30304==Address 0x42D564D4 is 0 bytes inside a block of size 36 free'd ==30304==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==30304==by 0x817ADBE: LyXText::removeRow(Row *) const (text2.C:377) ==30304==by 0x8171753: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==30304==by 0x8181124: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==30304== ==30304== Invalid read of size 2 ==30304==at 0x81796A2: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3674) ==30304==by 0x81554C1: LyXScreen::drawFromTo(LyXText *, BufferView *, int, int, int, int, bool) (lyxrow.h:139) ==30304==by 0x815531B: LyXScreen::redraw(LyXText *, BufferView *) (WorkArea.h:93) ==30304==by 0x8059F41: BufferView::Pimpl::workAreaExpose(void) (BufferView_pimpl.C:1052) ==30304==Address 0x42D564E0 is 12 bytes inside a block of size 36 free'd ==30304==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==30304==by 0x817ADBE: LyXText::removeRow(Row *) const (text2.C:377) ==30304==by 0x8171753: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==30304==by 0x8181124: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==30304== ==30304== Invalid read of size 4 ==30304==at 0x81393F6: Row::fill(void) const (lyxrow.C:52) ==30304==by 0x817971C: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3689) ==30304==by 0x81554C1: LyXScreen::drawFromTo(LyXText *, BufferView *, int, int, int, int, bool) (lyxrow.h:139
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-23 kl. 14:10 skrev Juergen Vigna: Sorry again what version of LyX are you using? Are you using the current cvs tree? I seem to see differences in the backtraces valgrind gives and the sourcecode (for example there is no row-previous() in draw!). Well it was built from CVS sometime last week. I have rebuild LyX with the current 1.2.0CVS and produced a new lyxlog.txt the same way as before. (Yes, the problem persists). Claus Hindsgaul ==4426== valgrind-20020422, a memory error detector for x86 GNU/Linux. ==4426== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==4426== For more details, rerun with: -v ==4426== --4426-- Warning: splitting giant basic block into pieces --4426-- Warning: splitting giant basic block into pieces --4426-- Warning: splitting giant basic block into pieces --4426-- Warning: splitting giant basic block into pieces ==4426== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==4426==at 0x40622414: (within /lib/libc-2.2.5.so) ==4426==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==4426==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==4426==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==4426== ==4426== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==4426==at 0x40622414: (within /lib/libc-2.2.5.so) ==4426==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==4426==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==4426==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==4426== ==4426== Invalid read of size 4 ==4426==at 0x8139496: Row::previous(void) const (lyxrow.C:112) ==4426==by 0x816E317: LyXText::draw(LyXText::DrawRowParams , int ) (text.C:650) ==4426==by 0x8179658: LyXText::paintRowText(LyXText::DrawRowParams ) (text.C:3665) ==4426==by 0x81797E0: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==4426==Address 0x42D62B9C is 32 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==4426==by 0x817AD9E: LyXText::removeRow(Row *) const (text2.C:377) ==4426==by 0x8171733: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==4426==by 0x8181104: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==4426== ==4426== Invalid read of size 4 ==4426==at 0x816D993: LyXText::drawInset(LyXText::DrawRowParams , int) (lyxrow.h:91) ==4426==by 0x816E317: LyXText::draw(LyXText::DrawRowParams , int ) (text.C:650) ==4426==by 0x8179658: LyXText::paintRowText(LyXText::DrawRowParams ) (text.C:3665) ==4426==by 0x81797E0: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==4426==Address 0x42D62B7C is 0 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==4426==by 0x817AD9E: LyXText::removeRow(Row *) const (text2.C:377) ==4426==by 0x8171733: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==4426==by 0x8181104: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==4426== ==4426== Invalid read of size 2 ==4426==at 0x8179682: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3674) ==4426==by 0x81554A1: LyXScreen::drawFromTo(LyXText *, BufferView *, int, int, int, int, bool) (lyxrow.h:139) ==4426==by 0x81552FB: LyXScreen::redraw(LyXText *, BufferView *) (WorkArea.h:93) ==4426==by 0x8059F41: BufferView::Pimpl::workAreaExpose(void) (BufferView_pimpl.C:1052) ==4426==Address 0x42D62B88 is 12 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==4426==by 0x817AD9E: LyXText::removeRow(Row *) const (text2.C:377) ==4426==by 0x8171733: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==4426==by 0x8181104: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==4426== ==4426== Invalid read of size 4 ==4426==at 0x8139406: Row::fill(void) const (lyxrow.C:52) ==4426==by 0x81796FC: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3689) ==4426==by 0x81554A1: LyXScreen::drawFromTo(LyXText *, BufferView *, int, int, int, int, bool) (lyxrow.h:139) ==4426==by 0x81552FB: LyXScreen::redraw(LyXText *, BufferView *) (WorkArea.h:93) ==4426==Address 0x42D62B84 is 8 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==4426==by 0x817AD9E: LyXText::removeRow
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-23 kl. 11:18 skrev Jean-Marc Lasgouttes: > If you have time, you may want to try our valgrind > http://developer.kde.org/~sewardj/ I tried it by simply invoking 'valgrind lyx'. The crash did NOT happen within valgrind, but a lot of messages were output at the expected time of the crash. I have attached the output for the two cases excactly as described in my earlier posting: * lyxlog.txt: With the crash messages (but no actual crash within valgrind), LC_ALL=da_DK, scalable fonts option DEACTIVATED * lyxlog_ok.txt: No crash, LC_ALL=da_DK, but the scalable fonts option ACTIVATED Claus Hindsgaul ==30304== valgrind-20020422, a memory error detector for x86 GNU/Linux. ==30304== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==30304== For more details, rerun with: -v ==30304== --30304-- Warning: splitting giant basic block into pieces --30304-- Warning: splitting giant basic block into pieces --30304-- Warning: splitting giant basic block into pieces --30304-- Warning: splitting giant basic block into pieces ==30304== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==30304==at 0x40622414: (within /lib/libc-2.2.5.so) ==30304==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==30304==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==30304==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==30304== ==30304== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==30304==at 0x40622414: (within /lib/libc-2.2.5.so) ==30304==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==30304==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==30304==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==30304==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==30304== ==30304== Invalid read of size 4 ==30304==at 0x8139486: Row::previous(void) const (lyxrow.C:112) ==30304==by 0x816E337: LyXText::draw(LyXText::DrawRowParams &, int &) (text.C:650) ==30304==by 0x8179678: LyXText::paintRowText(LyXText::DrawRowParams &) (text.C:3665) ==30304==by 0x8179800: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==30304==Address 0x42D564F4 is 32 bytes inside a block of size 36 free'd ==30304==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==30304==by 0x817ADBE: LyXText::removeRow(Row *) const (text2.C:377) ==30304==by 0x8171753: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==30304==by 0x8181124: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==30304== ==30304== Invalid read of size 4 ==30304==at 0x816D9B3: LyXText::drawInset(LyXText::DrawRowParams &, int) (lyxrow.h:91) ==30304==by 0x816E337: LyXText::draw(LyXText::DrawRowParams &, int &) (text.C:650) ==30304==by 0x8179678: LyXText::paintRowText(LyXText::DrawRowParams &) (text.C:3665) ==30304==by 0x8179800: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==30304==Address 0x42D564D4 is 0 bytes inside a block of size 36 free'd ==30304==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==30304==by 0x817ADBE: LyXText::removeRow(Row *) const (text2.C:377) ==30304==by 0x8171753: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==30304==by 0x8181124: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==30304== ==30304== Invalid read of size 2 ==30304==at 0x81796A2: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3674) ==30304==by 0x81554C1: LyXScreen::drawFromTo(LyXText *, BufferView *, int, int, int, int, bool) (lyxrow.h:139) ==30304==by 0x815531B: LyXScreen::redraw(LyXText *, BufferView *) (WorkArea.h:93) ==30304==by 0x8059F41: BufferView::Pimpl::workAreaExpose(void) (BufferView_pimpl.C:1052) ==30304==Address 0x42D564E0 is 12 bytes inside a block of size 36 free'd ==30304==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==30304==by 0x817ADBE: LyXText::removeRow(Row *) const (text2.C:377) ==30304==by 0x8171753: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==30304==by 0x8181124: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==30304== ==30304== Invalid read of size 4 ==30304==at 0x81393F6: Row::fill(void) const (lyxrow.C:52) ==30304==by 0x817971C: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3689) ==30304==by 0x81554C1: LyXScreen::drawFromTo(LyXText *, Buffe
Re: Language specific crash in LyX 1.2.0cvs
tir, 2002-04-23 kl. 14:10 skrev Juergen Vigna: > Sorry again what version of LyX are you using? Are you using the current > cvs tree? I seem to see differences in the backtraces valgrind gives and > the sourcecode (for example there is no row->previous() in draw!). Well it was built from CVS sometime last week. I have rebuild LyX with the current 1.2.0CVS and produced a new lyxlog.txt the same way as before. (Yes, the problem persists). Claus Hindsgaul ==4426== valgrind-20020422, a memory error detector for x86 GNU/Linux. ==4426== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==4426== For more details, rerun with: -v ==4426== --4426-- Warning: splitting giant basic block into pieces --4426-- Warning: splitting giant basic block into pieces --4426-- Warning: splitting giant basic block into pieces --4426-- Warning: splitting giant basic block into pieces ==4426== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==4426==at 0x40622414: (within /lib/libc-2.2.5.so) ==4426==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==4426==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==4426==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==4426== ==4426== Syscall param write(buf) contains uninitialised or unaddressable byte(s) ==4426==at 0x40622414: (within /lib/libc-2.2.5.so) ==4426==by 0x40467E83: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x4044C9DC: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==Address 0x424BA452 is 938 bytes inside a block of size 2048 alloc'd ==4426==at 0x4003CEEC: calloc (vg_clientfuncs.c:202) ==4426==by 0x40440236: (within /usr/X11R6/lib/libX11.so.6.2) ==4426==by 0x40317009: (within /usr/X11R6/lib/libforms.so.0.89) ==4426== ==4426== Invalid read of size 4 ==4426==at 0x8139496: Row::previous(void) const (lyxrow.C:112) ==4426==by 0x816E317: LyXText::draw(LyXText::DrawRowParams &, int &) (text.C:650) ==4426==by 0x8179658: LyXText::paintRowText(LyXText::DrawRowParams &) (text.C:3665) ==4426==by 0x81797E0: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==4426==Address 0x42D62B9C is 32 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==4426==by 0x817AD9E: LyXText::removeRow(Row *) const (text2.C:377) ==4426==by 0x8171733: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==4426==by 0x8181104: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==4426== ==4426== Invalid read of size 4 ==4426==at 0x816D993: LyXText::drawInset(LyXText::DrawRowParams &, int) (lyxrow.h:91) ==4426==by 0x816E317: LyXText::draw(LyXText::DrawRowParams &, int &) (text.C:650) ==4426==by 0x8179658: LyXText::paintRowText(LyXText::DrawRowParams &) (text.C:3665) ==4426==by 0x81797E0: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3724) ==4426==Address 0x42D62B7C is 0 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==4426==by 0x817AD9E: LyXText::removeRow(Row *) const (text2.C:377) ==4426==by 0x8171733: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==4426==by 0x8181104: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==4426== ==4426== Invalid read of size 2 ==4426==at 0x8179682: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3674) ==4426==by 0x81554A1: LyXScreen::drawFromTo(LyXText *, BufferView *, int, int, int, int, bool) (lyxrow.h:139) ==4426==by 0x81552FB: LyXScreen::redraw(LyXText *, BufferView *) (WorkArea.h:93) ==4426==by 0x8059F41: BufferView::Pimpl::workAreaExpose(void) (BufferView_pimpl.C:1052) ==4426==Address 0x42D62B88 is 12 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.c:171) ==4426==by 0x817AD9E: LyXText::removeRow(Row *) const (text2.C:377) ==4426==by 0x8171733: LyXText::breakAgain(BufferView *, Row *) const (text.C:1653) ==4426==by 0x8181104: LyXText::checkParagraph(BufferView *, Paragraph *, int) (text2.C:1961) ==4426== ==4426== Invalid read of size 4 ==4426==at 0x8139406: Row::fill(void) const (lyxrow.C:52) ==4426==by 0x81796FC: LyXText::getVisibleRow(BufferView *, int, int, Row *, int, bool) (text.C:3689) ==4426==by 0x81554A1: LyXScreen::drawFromTo(LyXText *, BufferView *, int, int, int, int, bool) (lyxrow.h:139) ==4426==by 0x81552FB: LyXScreen::redraw(LyXText *, BufferView *) (WorkArea.h:93) ==4426==Address 0x42D62B84 is 8 bytes inside a block of size 36 free'd ==4426==at 0x4003CDC2: __builtin_delete (vg_clientfuncs.
XForms source, where?
fre, 2002-04-19 kl. 02:02 skrev John Levon: On Thu, Apr 18, 2002 at 04:23:00PM +0200, Claus Hindsgaul wrote: 2) Use a locale != da_DK. (E.g. C, no_NO, de_AT works) I can't reproduce a problem myself. Can you try the open source xforms perhaps ? OK, I give in and want to try it out but... Is the XForms source available yet? Where? Claus
XForms source, where?
fre, 2002-04-19 kl. 02:02 skrev John Levon: > On Thu, Apr 18, 2002 at 04:23:00PM +0200, Claus Hindsgaul wrote: > > > 2) Use a locale != da_DK. (E.g. C, no_NO, de_AT works) > > I can't reproduce a problem myself. Can you try the open source xforms > perhaps ? OK, I give in and want to try it out but... Is the XForms source available yet? Where? Claus
Re: Language specific crash in LyX 1.2.0cvs
Hi again,
With a little help from Jean-Marc I have produced the following output
from gdb while triggering the described crash.
I hope it may help you nail it down.
Claus
(gdb) run
Starting program: /usr/local/bin/lyx
Program received signal SIGSEGV, Segmentation fault.
LyXText::drawInset (this=0x8453d70, p=@0xb244, pos=20) at text.C:495
495 if (prev prev-par() == p.row-par()) {
(gdb) bt
#0 LyXText::drawInset (this=0x8453d70, p=@0xb244, pos=20) at text.C:495
#1 0x0816dee7 in LyXText::draw (this=0x8453d70, p=@0xb244,
vpos=@0xb1e0) at text.C:649
#2 0x08179228 in LyXText::paintRowText (this=0x8453d70, p=@0xb244)
at text.C:3665
#3 0x081793b0 in LyXText::getVisibleRow (this=0x8453d70, bv=0x843e3e0,
y_offset=56, x_offset=0, row=0x847b110, y=56, cleared=false) at text.C:3723 #4
0x08154fe1 in LyXScreen::drawFromTo (this=0x8485038, text=0x8453d70,
bv=0x843e3e0, y1=0, y2=414, y_offset=0, x_offset=0, internal=true)
at screen.C:130
#5 0x08154eeb in LyXScreen::redraw (this=0x8485038, text=0x8453d70,
bv=0x843e3e0) at screen.C:92
#6 0x08059ec1 in BufferView::Pimpl::workAreaExpose (this=0x843e530)
at BufferView_pimpl.C:1031
#7 0x08068b32 in SigC::ObjectSlot0_void, BufferView::Pimpl::callback (
d=0x843ef94) at ../sigc++/object_slot.h:56
#8 0x08055674 in SigC::Signal0void, SigC::Marshalvoid ::emit (
this=0x843e55c) at ../../sigc++/basic_signal.h:194
#9 0x080a134d in WorkArea::work_area_handler (ob=0x843edc8, event=1, key=0,
xev=0x0) at ../sigc++/basic_signal.h:172
#10 0x080a04b6 in C_WorkArea_work_area_handler (ob=0x843edc8, event=1, key=0,
xev=0x0) at WorkArea.C:68
---Type return to continue, or q return to quit---
#11 0x400818f3 in fl_reset_focus_object () from /usr/X11R6/lib/libforms.so.0.89 #12
0x400819b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#13 0x400812c8 in fl_find_last () from /usr/X11R6/lib/libforms.so.0.89
#14 0x400813cb in fl_redraw_object () from /usr/X11R6/lib/libforms.so.0.89
#15 0x080578c4 in BufferView::Pimpl::redraw (this=0x843e530) at WorkArea.h:53
#16 0x08057fe6 in BufferView::Pimpl::resizeCurrentBuffer (this=0x843e530)
at BufferView_pimpl.C:379
#17 0x080575f1 in BufferView::Pimpl::buffer (this=0x843e530, b=0x8452478)
at BufferView_pimpl.C:212
#18 0x08050ceb in BufferView::buffer (this=0x843e3e0, b=0x8452478)
at BufferView.C:64
#19 0x0811cbe8 in LyXFunc::open (this=0x840bd78, fname=@0xb9e0)
at lyxfunc.C:1899
#20 0x08115260 in LyXFunc::dispatch (this=0xb9e0, action=LFUN_FILE_OPEN,
argument=0xb9e0) at lyxfunc.C:1340
#21 0x0828 in LyXFunc::verboseDispatch (this=0x840bd78,
action=LFUN_FILE_OPEN, argument=@0xba24, show_sc=true) at lyxfunc.C:799
#22 0x08111079 in LyXFunc::verboseDispatch (this=0x840bd78, ac=461,
show_sc=true) at lyxfunc.C:791
#23 0x082af0c8 in Menubar::Pimpl::MenuCallback (ob=0x8437fb0, button=1)
at Menubar_pimpl.C:586
#24 0x082a88a4 in C_Menubar_Pimpl_MenuCallback (ob=0x8437fb0, button=1)
---Type return to continue, or q return to quit---
at Menubar_pimpl.C:80
#25 0x40046cb4 in fl_object_qread () from /usr/X11R6/lib/libforms.so.0.89
#26 0x40057679 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#27 0x082a7b39 in GUIRunTime::runTime () at GUIRunTime.C:94
#28 0x080fbe44 in LyXGUI::runTime (this=0x83cc6a0) at lyx_gui.C:292
#29 0x080fc996 in LyX::LyX (this=0xbbdc, argc=0xbc04, argv=0xbc64)
at ../src/lyx_main.C:176
#30 0x08145db6 in main (argc=1, argv=0xbc64) at ../src/main.C:38
#31 0x402b317f in __libc_start_main () from /lib/libc.so.6
Re: Language specific crash in LyX 1.2.0cvs
Hi again,
With a little help from Jean-Marc I have produced the following output
from gdb while triggering the described crash.
I hope it may help you nail it down.
Claus
(gdb) run
Starting program: /usr/local/bin/lyx
Program received signal SIGSEGV, Segmentation fault.
LyXText::drawInset (this=0x8453d70, p=@0xb244, pos=20) at text.C:495
495 if (prev && prev->par() == p.row->par()) {
(gdb) bt
#0 LyXText::drawInset (this=0x8453d70, p=@0xb244, pos=20) at text.C:495
#1 0x0816dee7 in LyXText::draw (this=0x8453d70, p=@0xb244,
vpos=@0xb1e0) at text.C:649
#2 0x08179228 in LyXText::paintRowText (this=0x8453d70, p=@0xb244)
at text.C:3665
#3 0x081793b0 in LyXText::getVisibleRow (this=0x8453d70, bv=0x843e3e0,
y_offset=56, x_offset=0, row=0x847b110, y=56, cleared=false) at text.C:3723 #4
0x08154fe1 in LyXScreen::drawFromTo (this=0x8485038, text=0x8453d70,
bv=0x843e3e0, y1=0, y2=414, y_offset=0, x_offset=0, internal=true)
at screen.C:130
#5 0x08154eeb in LyXScreen::redraw (this=0x8485038, text=0x8453d70,
bv=0x843e3e0) at screen.C:92
#6 0x08059ec1 in BufferView::Pimpl::workAreaExpose (this=0x843e530)
at BufferView_pimpl.C:1031
#7 0x08068b32 in SigC::ObjectSlot0_::callback (
d=0x843ef94) at ../sigc++/object_slot.h:56
#8 0x08055674 in SigC::Signal0::emit (
this=0x843e55c) at ../../sigc++/basic_signal.h:194
#9 0x080a134d in WorkArea::work_area_handler (ob=0x843edc8, event=1, key=0,
xev=0x0) at ../sigc++/basic_signal.h:172
#10 0x080a04b6 in C_WorkArea_work_area_handler (ob=0x843edc8, event=1, key=0,
xev=0x0) at WorkArea.C:68
---Type to continue, or q to quit---
#11 0x400818f3 in fl_reset_focus_object () from /usr/X11R6/lib/libforms.so.0.89 #12
0x400819b5 in fl_handle_object () from /usr/X11R6/lib/libforms.so.0.89
#13 0x400812c8 in fl_find_last () from /usr/X11R6/lib/libforms.so.0.89
#14 0x400813cb in fl_redraw_object () from /usr/X11R6/lib/libforms.so.0.89
#15 0x080578c4 in BufferView::Pimpl::redraw (this=0x843e530) at WorkArea.h:53
#16 0x08057fe6 in BufferView::Pimpl::resizeCurrentBuffer (this=0x843e530)
at BufferView_pimpl.C:379
#17 0x080575f1 in BufferView::Pimpl::buffer (this=0x843e530, b=0x8452478)
at BufferView_pimpl.C:212
#18 0x08050ceb in BufferView::buffer (this=0x843e3e0, b=0x8452478)
at BufferView.C:64
#19 0x0811cbe8 in LyXFunc::open (this=0x840bd78, fname=@0xb9e0)
at lyxfunc.C:1899
#20 0x08115260 in LyXFunc::dispatch (this=0xb9e0, action=LFUN_FILE_OPEN,
argument=0xb9e0) at lyxfunc.C:1340
#21 0x0828 in LyXFunc::verboseDispatch (this=0x840bd78,
action=LFUN_FILE_OPEN, argument=@0xba24, show_sc=true) at lyxfunc.C:799
#22 0x08111079 in LyXFunc::verboseDispatch (this=0x840bd78, ac=461,
show_sc=true) at lyxfunc.C:791
#23 0x082af0c8 in Menubar::Pimpl::MenuCallback (ob=0x8437fb0, button=1)
at Menubar_pimpl.C:586
#24 0x082a88a4 in C_Menubar_Pimpl_MenuCallback (ob=0x8437fb0, button=1)
---Type to continue, or q to quit---
at Menubar_pimpl.C:80
#25 0x40046cb4 in fl_object_qread () from /usr/X11R6/lib/libforms.so.0.89
#26 0x40057679 in fl_check_forms () from /usr/X11R6/lib/libforms.so.0.89
#27 0x082a7b39 in GUIRunTime::runTime () at GUIRunTime.C:94
#28 0x080fbe44 in LyXGUI::runTime (this=0x83cc6a0) at lyx_gui.C:292
#29 0x080fc996 in LyX::LyX (this=0xbbdc, argc=0xbc04, argv=0xbc64)
at ../src/lyx_main.C:176
#30 0x08145db6 in main (argc=1, argv=0xbc64) at ../src/main.C:38
#31 0x402b317f in __libc_start_main () from /lib/libc.so.6
Language specific crash in LyX 1.2.0cvs
Hi, Using the current Danish LyX 1.2.0, I have noticed a strange crash while opening a couple of similar documents. LyX catches a SIGSEGV signal without further notice while opening the documents. The crash is avioded if: 1) I activate Rescale bitmap fonts in preferences before opening the document. It is OK to open the document with this feature turned ON. I can even deactivate it after the document is loaded without causing trouble. Thus the error seems to happen only in the process of loading a document. or 2) Use a locale != da_DK. (E.g. C, no_NO, de_AT works) I am myself the translator of the Danish po file for LyX and can not find any formating errors in it. Maybe someone else can? The last lines in the output from 'lyx -debug 5' are: -- PopUP Event(6,w=0x360009e s=2081) MotionNotify Mode Hint PopUP Event(6,w=0x360009e s=2082) MotionNotify Mode Hint PopUP Event(5,w=0x360009e s=2098) ButtonRelease button: 1 PopClose Event(18,w=0x360009e s=2102) UnmapNotify lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help-Introduction and send us a bug report, if necessary. Thanks ! Bye. Afbrudt (SIGABRT) bash-2.05a$ The system is Debian Woody, libforms 0.89. Claus Hindsgaul
Language specific crash in LyX 1.2.0cvs
Hi, Using the current Danish LyX 1.2.0, I have noticed a strange crash while opening a couple of similar documents. LyX catches a SIGSEGV signal without further notice while opening the documents. The crash is avioded if: 1) I activate "Rescale bitmap fonts" in preferences before opening the document. It is OK to open the document with this feature turned ON. I can even deactivate it after the document is loaded without causing trouble. Thus the error seems to happen only in the process of loading a document. or 2) Use a locale != da_DK. (E.g. C, no_NO, de_AT works) I am myself the translator of the Danish po file for LyX and can not find any formating errors in it. Maybe someone else can? The last lines in the output from 'lyx -debug 5' are: -- PopUP Event(6,w=0x360009e s=2081) MotionNotify Mode Hint PopUP Event(6,w=0x360009e s=2082) MotionNotify Mode Hint PopUP Event(5,w=0x360009e s=2098) ButtonRelease button: 1 PopClose Event(18,w=0x360009e s=2102) UnmapNotify lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help->Introduction and send us a bug report, if necessary. Thanks ! Bye. Afbrudt (SIGABRT) bash-2.05a$ The system is Debian Woody, libforms 0.89. Claus Hindsgaul
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
Angus wrote. In other words I can not get a 270 degree rotation no matter how the figure was recently rotated. Claus Why the hell are the output images affected? I _really_ don't believe you there. Well it _really_ happens :-). I just noticed that I got this error message on the terminal when failing to rotate by 270 (or -90) degrees: In RotateMatrix [image_rotate.c 239] InternalError: bad special angle Claus
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
fre, 2002-04-12 kl. 12:01 skrev Angus Leeming: Please tell me if you can't rotate the LaTeX output image by 270 degs. == The LaTeX-output is fine, so this is only a display problem after all - and obviously known and being fixed. Thanks. Claus
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
Angus wrote. >> In other words I can not get a 270 degree rotation no matter how the >> figure was recently rotated. >> >> Claus > >Why the hell are the output images affected? I _really_ don't believe >you >there. Well it _really_ happens :-). I just noticed that I got this error message on the terminal when failing to rotate by 270 (or -90) degrees: In RotateMatrix [image_rotate.c 239] InternalError: bad special angle Claus
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
fre, 2002-04-12 kl. 12:01 skrev Angus Leeming: > Please tell me if you can't rotate the LaTeX output image by 270 degs. > == The LaTeX-output is fine, so this is only a display problem after all - and obviously known and being fixed. Thanks. Claus
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
In other words I can not get a 270 degree rotation no matter how the figure was recently rotated. Can't confirm that. I'm using 1.2.0cvs here on FreeBSD PC. I'm with Debian testing, libforms-bin version 0.89-2. Maybe the problem will simply go away with a more recent libforms library. I'll wait and see... Claus
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
> > In other words I can not get a 270 degree rotation no matter how the > > figure was recently rotated. > > Can't confirm that. I'm using 1.2.0cvs here on FreeBSD PC. I'm with Debian testing, libforms-bin version 0.89-2. Maybe the problem will simply go away with a more recent libforms library. I'll wait and see... Claus
Cant rotate by 270 degrees
Hi, Using the current 1.2.0cvs I just noticed that I cant rotate graphics by 270 degrees. 90, 180, 269 and 271 degrees work just fine --- just not 270 degrees... Clau
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
tir, 2002-04-09 kl. 14:38 skrev R. Lahaye: But now do the following series: 0 : LyX View updates to 0 degrees 268 : LyX View updates to 268 degrees 269 : nothing happens 270 : LyX View updates to 270 degrees 271 : nothing happens Did you actually look at the figure at 270 degrees? I have excactly the same apparent result as you have above, but at 270 degrees the dialog indeed accept the value - but the displayed figures is updated from 268 degrees rotation to ZERO degrees as are the pdf and ps output. In other words I can not get a 270 degree rotation no matter how the figure was recently rotated. Claus
Cant rotate by 270 degrees
Hi, Using the current 1.2.0cvs I just noticed that I cant rotate graphics by 270 degrees. 90, 180, 269 and 271 degrees work just fine --- just not 270 degrees... Clau
Re: Bug in graphics rotation (Was: Cant rotate by 270 degrees)
tir, 2002-04-09 kl. 14:38 skrev R. Lahaye: > But now do the following series: > > 0 : LyX View updates to 0 degrees > 268 : LyX View updates to 268 degrees > 269 : nothing happens > 270 : LyX View updates to 270 degrees > 271 : nothing happens Did you actually look at the figure at 270 degrees? I have excactly the same apparent result as you have above, but at 270 degrees the dialog indeed accept the value - but the displayed figures is updated from 268 degrees rotation to ZERO degrees as are the pdf and ps output. In other words I can not get a 270 degree rotation no matter how the figure was recently rotated. Claus
Missing translations
Hi, After having tested the Danish LyX 1.2.0, I have noticed a few untranslated items: In the language drop-down menus, all languages (afrikaans, american, arabic...) are in English even though they were all translated in the po-file. The unit drop-down menus share the same flaw (cm, mm, in, text%...) The help texts in the bottom of the preferences dialog also appear in English even though they were translated in the po-file. Will anyone fix the previously reported typo: src/ext_l10n.h:1000 src/ext_l10n.h:1002: Margin by with paragraph is allowed to increase s/with/which/ Nice improvements BTW. I love being able to insert jpg graphics directly into LyX. One wishlist item: \circ, \dag and \ddag soon become rendered in LyX, as I use them quite often. Sincerely, Claus Hindsgaul
Reproducible crash in several translations
Hi again, I have a reproducible crash when the tabs of the preferences dialog (Look Feel, Lang Opts...) are translated into another language causing longer strings. Pressing the last tab (originally Output) crashes LyX with the messages below. I have reproduced the crash in German, Danish and Norwegian. The problem was fixed in Danish, when I shortened the translated strings in the po file to fit into the window. The problem should be solved in the code if possible - rather than in the translations Claus bash-2.05a$ LC_ALL=no_NO lyx lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. Please read the bug-reporting instructions in Help-Introduction and send us a bug report, if necessary. Thanks ! Bye. Afbrudt (SIGABRT) bash-2.05a$
Missing translations
Hi, After having tested the Danish LyX 1.2.0, I have noticed a few untranslated items: In the language drop-down menus, all languages (afrikaans, american, arabic...) are in English even though they were all translated in the po-file. The unit drop-down menus share the same flaw (cm, mm, in, text%...) The help texts in the bottom of the preferences dialog also appear in English even though they were translated in the po-file. Will anyone fix the previously reported typo: > src/ext_l10n.h:1000 src/ext_l10n.h:1002: > "Margin by with paragraph is allowed to increase" s/with/which/ Nice improvements BTW. I love being able to insert jpg graphics directly into LyX. One wishlist item: \circ, \dag and \ddag soon become rendered in LyX, as I use them quite often. Sincerely, Claus Hindsgaul
Reproducible crash in several translations
Hi again,
I have a reproducible crash when the tabs of the preferences dialog
("Look & Feel", "Lang Opts"...) are translated into another language
causing longer strings. Pressing the last tab (originally "Output")
crashes LyX with the messages below.
I have reproduced the crash in German, Danish and Norwegian. The problem
was fixed in Danish, when I shortened the translated strings in the po
file to fit into the window.
The problem should be solved in the code if possible - rather than in
the translations
Claus
bash-2.05a$ LC_ALL=no_NO lyx
lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help->Introduction and send us a bug report, if
necessary. Thanks !
Bye.
Afbrudt (SIGABRT)
bash-2.05a$
Two questions from a translator
Hi, I have just finished the Danish translation of lyx 1.2.0pre1 and mailed it to Lars (did I win the price for fast response? :) ) I found to strings that I do not understand. Could someone please explain them to me - or correct the strings in the source if they are actually wrong: src/ext_l10n.h:325: mainline (My dictionary writes somthing about junkies and nurses injecting drugs directly into the blood, hmm...) and src/ext_l10n.h:1000 src/ext_l10n.h:1002: Margin by with paragraph is allowed to increase Cheers, Claus Hindsgaul (Please cc: me)
Two questions from a translator
Hi, I have just finished the Danish translation of lyx 1.2.0pre1 and mailed it to Lars (did I win the price for fast response? :) ) I found to strings that I do not understand. Could someone please explain them to me - or correct the strings in the source if they are actually wrong: src/ext_l10n.h:325: "mainline" (My dictionary writes somthing about junkies and nurses injecting drugs directly into the blood, hmm...) and src/ext_l10n.h:1000 src/ext_l10n.h:1002: "Margin by with paragraph is allowed to increase" Cheers, Claus Hindsgaul (Please cc: me)
1.2.0 matured for translation?
Hi, How stable do you consider the set of translatable strings in LyX 1.2.0? Is it about time to begin updating the international translation of xx.po? If so, it might be an idea to run 'make update-po' to sync the po files preparing them for the translators. If not, I'll just *try* to accept that I'll have to be very patient waiting for a new version of my favourite text processor. :) Sincerely Claus Hindsgaul (Please cc: )
1.2.0 matured for translation?
Hi, How stable do you consider the set of translatable strings in LyX 1.2.0? Is it about time to begin updating the international translation of xx.po? If so, it might be an idea to run 'make update-po' to sync the po files preparing them for the translators. If not, I'll just *try* to accept that I'll have to be very patient waiting for a new version of my favourite text processor. :) Sincerely Claus Hindsgaul (Please cc: )
Announcing danish translation
Hi lyx-developers! I have produced a complete update of the three years old danish gettext po-file for LyX 1.1.6. Since no danish maintainer exist, you can set me up as a maintainer. I currently have no plans to work on the documentation, but who knows... BTW. my translation does not fix the extended refs (aka PrettyRef: "Table 4 on the next page"). This really hurts when writing native docs. Is this due to shortcomings of a LyX or LaTeX package? Please let me know how to submit my file. -- Claus Hindsgaul Reberbanegade 53, 4. th - 2300 KBH S Tlf (+45) 3297 3640 [EMAIL PROTECTED] (PGP-ngle: http://www.image.dk/~claus_h/PGP.htm )
Re: Announcing danish translation
January 26. 2001 Jean-Marc Lasgouttes wrote:
The problem is that the prettyref package doesn't support other languages.
You need to redefine the labels for it in the preamble (or edit
prettyref.sty) For example:
\newrefformat{cha}{\chaptername~\ref{#1}}
\newrefformat{tab}{\tablename~\ref{#1}}
etc.
However, there is no \sectionname in babel, so you need to use the Danish
word for section.
Thank you for the clarification..
If I do so, the error will reappear when other people retrieve my
LyX-documents. What a mess... :( .
Maybe we should include information in the LyX menus, which depreciate the
use of PrettyRef for foreign languages...
Claus Hindsgaul
--
Claus Hindsgaul
Reberbanegade 53, 4. th - 2300 KBH S
Tlf (+45) 3297 3640
[EMAIL PROTECTED] (PGP-ngle: http://www.image.dk/~claus_h/PGP.htm )
Re: Announcing danish translation
Woops - pasted the wrong name :) The credits should go to Dekel Tsur, sorry. Claus January 26. 2001 Jean-Marc Lasgouttes wrote: The problem is that the prettyref package doesn't support other [...] Did I actually write that? That must have been during my sleep :) JMarc -- Claus Hindsgaul Reberbanegade 53, 4. th - 2300 KBH S Tlf (+45) 3297 3640 [EMAIL PROTECTED] (PGP-ngle: http://www.image.dk/~claus_h/PGP.htm )
Announcing danish translation
Hi lyx-developers! I have produced a complete update of the three years old danish gettext po-file for LyX 1.1.6. Since no danish maintainer exist, you can set me up as a maintainer. I currently have no plans to work on the documentation, but who knows... BTW. my translation does not fix the extended refs (aka PrettyRef: "Table 4 on the next page"). This really hurts when writing native docs. Is this due to shortcomings of a LyX or LaTeX package? Please let me know how to submit my file. -- Claus Hindsgaul Reberbanegade 53, 4. th - 2300 KBH S Tlf (+45) 3297 3640 [EMAIL PROTECTED] (PGP-nøgle: http://www.image.dk/~claus_h/PGP.htm )
Re: Announcing danish translation
January 26. 2001 Jean-Marc Lasgouttes wrote:
> The problem is that the prettyref package doesn't support other languages.
> You need to redefine the labels for it in the preamble (or edit
> prettyref.sty) For example:
>
> \newrefformat{cha}{\chaptername~\ref{#1}}
> \newrefformat{tab}{\tablename~\ref{#1}}
> etc.
> However, there is no \sectionname in babel, so you need to use the Danish
> word for section.
Thank you for the clarification..
If I do so, the error will reappear when other people retrieve my
LyX-documents. What a mess... :( .
Maybe we should include information in the LyX menus, which depreciate the
use of PrettyRef for foreign languages...
Claus Hindsgaul
--
Claus Hindsgaul
Reberbanegade 53, 4. th - 2300 KBH S
Tlf (+45) 3297 3640
[EMAIL PROTECTED] (PGP-nøgle: http://www.image.dk/~claus_h/PGP.htm )
Re: Announcing danish translation
Woops - pasted the wrong name :) The credits should go to Dekel Tsur, sorry. > Claus> January 26. 2001 Jean-Marc Lasgouttes wrote: > >> The problem is that the prettyref package doesn't support other > > [...] > > Did I actually write that? That must have been during my sleep :) > > JMarc -- Claus Hindsgaul Reberbanegade 53, 4. th - 2300 KBH S Tlf (+45) 3297 3640 [EMAIL PROTECTED] (PGP-nøgle: http://www.image.dk/~claus_h/PGP.htm )
