Re: core dump
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> clicking on e.g. greek in math panel core dumps lyx for me. John> anyone else ? 0.88, rh7 I can't reproduce this. What about a backtrace? JMarc
Re: core dump
On Wed, Jul 18, 2001 at 03:17:59PM +0200, Jean-Marc Lasgouttes wrote: > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > John> clicking on e.g. greek in math panel core dumps lyx for me. > John> anyone else ? 0.88, rh7 > > I can't reproduce this. What about a backtrace? It crashes in FormBaseDeprecated::show(), in the fl_freeze_form() in xforms. I think glibc got upgraded in redhat updates, probably I need a new xforms lib. thanks john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: core dump
John Levon wrote: > > clicking on e.g. greek in math panel core dumps lyx for me. anyone else ? > > 0.88, rh7 > > thanks > john > The problem persists. Any box from greek to Misc. If I go into math mode first I get an emergency save, otherwise not. Maybe this bug will disappear with the math panel. Can't seem to get to lyxbugs ATM. Garst
Re: core dump
On Thu, Jul 19, 2001 at 05:30:22PM -0300, Garst R. Reese wrote: > John Levon wrote: > > > > clicking on e.g. greek in math panel core dumps lyx for me. anyone else ? > > > > 0.88, rh7 > > > > thanks > > john > > > The problem persists. Any box from greek to Misc. If I go into math mode > first I get an emergency save, otherwise not. what compiler ? I get this with gcc 3.0 > Maybe this bug will disappear with the math panel. what do you mean ? > Can't seem to get to lyxbugs ATM. grr, damned sf ... john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: core dump
John Levon wrote: > what do you mean ? There have been rumblings for some time about the math panel and replacing it with some sort of tool bar, so I figured breaking it might be on the path. It's friday somewhere eh? Garst
Re: core dump
On Thu, Jul 19, 2001 at 09:34:25PM -0300, Garst R. Reese wrote: > John Levon wrote: > > > what do you mean ? > There have been rumblings for some time about the math panel and > replacing it with some sort of tool bar, so I figured breaking it might > be on the path. I see. The weird thing is there's been no real change to that code recently as far as I can see, since it was moved into frontends/xforms directory, so I don't know why it's stopped working. I compile w/o optimisation so I think it's less likely to be a compiler bug, I don't know ... john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: core dump
On Fri, Jul 20, 2001 at 12:46:40AM +0100, John Levon wrote: > > The problem persists. Any box from greek to Misc. If I go into math mode > > first I get an emergency save, otherwise not. > > what compiler ? I get this with gcc 3.0 ... and now it's gone. 0.88.9, gcc 3.0 ... p.s. I have a --disable-optimization patch for removing the -O is this ok for the tree ? it's a useful thing for devvies and users alike I think... regards john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: core dump
John Levon wrote: > > On Fri, Jul 20, 2001 at 12:46:40AM +0100, John Levon wrote: > > > > The problem persists. Any box from greek to Misc. If I go into math mode > > > first I get an emergency save, otherwise not. > > > > what compiler ? I get this with gcc 3.0 > > ... and now it's gone. 0.88.9, gcc 3.0 ... Still bombs here with 0.89.5, gcc 3.0 ... , but I can get greek with the kbd. Garst
Re: core dump
On Sat, Jul 21, 2001 at 10:01:41PM -0300, Garst R. Reese wrote: > > ... and now it's gone. 0.88.9, gcc 3.0 ... > Still bombs here with 0.89.5, gcc 3.0 ... , can others test please (JMarc, you don't get it either ?) ? > but I can get greek with the kbd. at least you can still get your work done then. john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: core dump
Jean-Marc Lasgouttes wrote: > > > "John" == John Levon <[EMAIL PROTECTED]> writes: > > John> On Sat, Jul 21, 2001 at 10:01:41PM -0300, Garst R. Reese wrote: > >> > ... and now it's gone. 0.88.9, gcc 3.0 ... Still bombs here with > >> 0.89.5, gcc 3.0 ... , > > John> can others test please (JMarc, you don't get it either ?) ? > > No. > > JMarc This is smelling like an uninitialized variable. Garst
Re: core dump
On Sun, Jul 22, 2001 at 02:50:31PM -0300, Garst R. Reese wrote: > This is smelling like an uninitialized variable. I don't think it's that simple a bug. I suspect an xforms bug of some kind, I'll see if I can get the bug again with a different version of xforms ... john -- "Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything." - Karl Lehenbauer
Re: core dump
John Levon wrote: > > On Sun, Jul 22, 2001 at 02:50:31PM -0300, Garst R. Reese wrote: > > > This is smelling like an uninitialized variable. > > I don't think it's that simple a bug. I suspect an xforms bug of some kind, > I'll see if I can get the bug again with a different version of xforms ... > > john No help here switching to 0.88.1 or compiling without optimization. Garst
Re: core dump
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes: Edwin> with today's cvs, clean checkout, am I the only one having Edwin> this? I see a lot of these on my gcc 2.96 build from mandrake 8.1. I am currently rebuilding with the gcc 2.96 from mandrake 8.2 to see whether it helps. The "tough" solution is to compile without optimization. JMarc
Re: core dump
On Tuesday 02 July 2002 14:12, Jean-Marc Lasgouttes wrote: > > "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes: > > Edwin> with today's cvs, clean checkout, am I the only one having > Edwin> this? > > I see a lot of these on my gcc 2.96 build from mandrake 8.1. I am > currently rebuilding with the gcc 2.96 from mandrake 8.2 to see > whether it helps. > > The "tough" solution is to compile without optimization. I had the same problem as you do, and --disable-optimization solve it. Here are the compilation times: real12m36.050s user11m36.050s sys 0m57.580s So now I can't get anymore those 7 min, I think that we are intending to establish some kind of Moore's Law. For every new version of LyX the compile time will double. I propose to call it Lars' Law, what do others think? ;-) > JMarc -- José Abílio
Re: core dump
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes: > | Edwin> with today's cvs, clean checkout, am I the only one having | Edwin> this? > | I see a lot of these on my gcc 2.96 build from mandrake 8.1. I am | currently rebuilding with the gcc 2.96 from mandrake 8.2 to see | whether it helps. > | The "tough" solution is to compile without optimization. Can you see if current CVS makes any difference? I have removed some static signals. -- Lgb
Re: core dump
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Can you see if current CVS makes any difference?
Lars> I have removed some static signals.
No luck. I still die with
(gdb) bt
#0 0x40328ca4 in free () from /lib/libc.so.6
#1 0x40328c24 in free () from /lib/libc.so.6
#2 0x08233cf7 in lyx_gui::init_graphics ()
#3 0x082f050b in grfx::Cache::get ()
#4 0x082f8ec5 in grfx::Loader::Impl::resetFile ()
#5 0x082fa0d5 in grfx::Loader::reset ()
#6 0x0821b4df in {anonymous}::SplashScreen::SplashScreen ()
#7 0x0821b0dc in {anonymous}::SplashScreen::get ()
#8 0x0821b58c in LyXScreen::LyXScreen ()
#9 0x0824a744 in XScreen::XScreen ()
#10 0x08233fab in LyXScreenFactory::create ()
#11 0x08055ead in BufferView::Pimpl::Pimpl ()
#12 0x0805193c in BufferView::BufferView ()
#13 0x08248293 in XFormsView::create_form_form_main ()
#14 0x08247739 in XFormsView::XFormsView ()
#15 0x082333f4 in lyx_gui::start ()
#16 0x080e44e4 in LyX::LyX ()
#17 0x0812a825 in main ()
#18 0x402c45b0 in __libc_start_main () from /lib/libc.so.6
Sorry for the lack of debug symbols, but I cannot afford them.
Maybe graphics should be initialized before the splash screen.
JMarc
Re: core dump
On Wednesday 03 July 2002 9:42 am, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Can you see if current CVS makes any difference?
>
> Lars> I have removed some static signals.
>
> No luck. I still die with
>
> (gdb) bt
> #0 0x40328ca4 in free () from /lib/libc.so.6
> #1 0x40328c24 in free () from /lib/libc.so.6
> #2 0x08233cf7 in lyx_gui::init_graphics ()
> #3 0x082f050b in grfx::Cache::get ()
> #4 0x082f8ec5 in grfx::Loader::Impl::resetFile ()
> #5 0x082fa0d5 in grfx::Loader::reset ()
> #6 0x0821b4df in {anonymous}::SplashScreen::SplashScreen ()
> #7 0x0821b0dc in {anonymous}::SplashScreen::get ()
> #8 0x0821b58c in LyXScreen::LyXScreen ()
> #9 0x0824a744 in XScreen::XScreen ()
> #10 0x08233fab in LyXScreenFactory::create ()
> #11 0x08055ead in BufferView::Pimpl::Pimpl ()
> #12 0x0805193c in BufferView::BufferView ()
> #13 0x08248293 in XFormsView::create_form_form_main ()
> #14 0x08247739 in XFormsView::XFormsView ()
> #15 0x082333f4 in lyx_gui::start ()
> #16 0x080e44e4 in LyX::LyX ()
> #17 0x0812a825 in main ()
> #18 0x402c45b0 in __libc_start_main () from /lib/libc.so.6
>
> Sorry for the lack of debug symbols, but I cannot afford them.
>
> Maybe graphics should be initialized before the splash screen.
>
> JMarc
They are automatically. The GraphicsCache is a singleton class that does all
the dirty work the first time it is get()ed.
If Lars believes that your compiler and static signals are a bad combination,
then he should think about these ones too. His current approach (in the
frontends) appears to be to remove functionality. I guess that's a try things
till they work approach?
Angus
/** \file graphics/GraphicsImage.h */
class Image {
public:
/** This is to be connected to a function that will return a new
* instance of a viable derived class.
*/
typedef boost::shared_ptr ImagePtr;
///
static boost::signal0 newImage;
/// Return the list of loadable formats.
typedef std::vector FormatList;
///
static boost::signal0 loadableFormats;
...
};
Re: core dump
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> They are automatically. The GraphicsCache is a singleton class Angus> that does all the dirty work the first time it is get()ed. That's what I see. What I was wondering is whether this class depends on some things being done before it does its dirty work. Also, could you try to run valgrind on your lyx binary to see whether there are problems with other compilers? JMarc
Re: core dump
Angus Leeming <[EMAIL PROTECTED]> writes: | If Lars believes that your compiler and static signals are a bad combination, | then he should think about these ones too. His current approach (in the | frontends) appears to be to remove functionality. I guess that's a try things | till they work approach? What functionality have I removed? -- Lgb
Re: core dump
On Wednesday 03 July 2002 10:06 am, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> They are automatically. The GraphicsCache is a singleton class > Angus> that does all the dirty work the first time it is get()ed. > > That's what I see. What I was wondering is whether this class depends > on some things being done before it does its dirty work. Nope. It does the dirty work of connecting these static signals to the required slots. > Also, could you try to run valgrind on your lyx binary to see whether > there are problems with other compilers? valgrind doesn't work on Alphas. Angus
Re: core dump
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: >> Also, could you try to run valgrind on your lyx binary to see >> whether there are problems with other compilers? Angus> valgrind doesn't work on Alphas. Excellent reason indeed. JMarc
Re: Core dump in 1.1.5cvs
Further to this email. It is very repeateable. Create a new doc. Create a figure float. Copy it and try pasting. Bam, it dumps. Table floats also cause a core dump. So do margin notes. Ben > > Hi Guys > > Was copying and pasting a figure float in the 1.1.5cvs RPM when it core dumped. > Attached is the trace from > gdb /usr/bin/lyxgdb core 2>&1 | tee lyxdump.txt > > Ben > Content-Type: text/english; name="lyxdump.txt" Content-Transfer-Encoding: base64 Content-Description: -- _ Ben Cazzolato Fluid Dynamics and Acoustics Group Institute of Sound and Vibration Research University of Southampton, Southampton, SO17 1BJ UK Email: [EMAIL PROTECTED], or [EMAIL PROTECTED], or [EMAIL PROTECTED], or Work: +44 (0)1703 594 967 Fax:+44 (0)1703 593 190 Mobile: +44 (0)790 163 8826 Web Page : http://www.soton.ac.uk/~bscazz/ _
Re: Core dump in 1.1.5cvs
Ben Cazzolato <[EMAIL PROTECTED]> writes: | Was copying and pasting a figure float in the 1.1.5cvs RPM when it | core dumped. Juergen applied a patch yesterday that should fix some of this. Can you try the updated cvs (or rpm) and try with that? Lgb
Re: Core dump in 1.1.5cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Ben Cazzolato <[EMAIL PROTECTED]> writes: | Was copying
Lars> and pasting a figure float in the 1.1.5cvs RPM when it | core
Lars> dumped.
Lars> Juergen applied a patch yesterday that should fix some of this.
Lars> Can you try the updated cvs (or rpm) and try with that?
There is still a problem when cutting multiple paragraphs. If I create
a document with two paragraphs and try to cut them, I get a Free
Memory Read from purify (log follows). I do not know the code very
well, so I don't know what to do now. Note that the first trace from
purify is probably wrong (does not make sense) so the problems
probably happens in CutAndPaste.C. The problems does not happen when
disabling Juergen's new cap code.
The problem does not seem to depend on whether the paragraphs are
first/last in the document or not.
JMarc
FMR: Free memory read (2 times)
This is occurring while in:
LyXParagraph::Next() [paragraph.C:1185]
// This function is able to hide closed footnotes.
LyXParagraph * LyXParagraph::Next()
{
=> if (next && next->footnoteflag ==
LyXParagraph::CLOSED_FOOTNOTE) {
LyXParagraph * tmp = next;
while (tmp
&& tmp->footnoteflag ==
LyXParagraph::CLOSED_FOOTNOTE)
BufferView::cut() [BufferView2.C:590]
LyXFunc::Dispatch(int,const char*) [lyxfunc.C:928]
LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:306]
LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:420]
C_LyXView_KeyPressMask_raw_callback [LyXView.C:452]
do_interaction_step [forms.c]
fl_treat_interaction_events [libforms.a]
fl_check_forms [libforms.a]
LyXGUI::runTime() [lyx_gui.C:621]
Reading 4 bytes from 0x637a2c in the heap.
Address 0x637a2c is 220 bytes into a freed block at 0x637950 of 256 bytes.
This block was allocated from:
malloc [rtlib.o]
__bUiLtIn_nEw [libgcc.a]
__builtin_new [rtlib.o]
LyXParagraph::BreakParagraphConservative(int) [paragraph.C:1558]
// create a new paragraph
LyXParagraph * par = ParFromPos(pos);
=> LyXParagraph * tmp = new LyXParagraph(par);
tmp->MakeSameLayout(par);
cutSelection__11CutAndPasteP12LyXParagraphPP12LyXParagraphiRicb
[CutAndPaste.C:87]
}
} else {
// more than one paragraph
=> (*endpar)->BreakParagraphConservative(end);
*endpar = (*endpar)->Next();
end = 0;
CutSelection__7LyXTextb [text2.C:2220]
cap.cutSelection(sel_start_cursor.par, &endpar,
sel_start_cursor.pos, sel_end_cursor.pos,
=> buffer->params.textclass, doclear);
cursor.par = sel_end_cursor.par = endpar;
cursor.pos = sel_end_cursor.pos;
}
BufferView::cut() [BufferView2.C:590]
LyXFunc::Dispatch(int,const char*) [lyxfunc.C:928]
LyXFunc::processKeyEvent(_XEvent*) [lyxfunc.C:306]
LyXView::KeyPressMask_raw_callback(forms_*,void*) [LyXView.C:420]
There have been 0 frees since this block was freed from:
free [rtlib.o]
__bUiLtIn_dElEtE [libgcc.a]
__builtin_delete [rtlib.o]
LyXParagraph::~LyXParagraph() [paragraph.C:519]
//
//lyxerr << "LyXParagraph::paragraph_id = "
// << LyXParagraph::paragraph_id << endl;
=> }
void LyXParagraph::Erase(LyXParagraph::size_type pos)
LyXParagraph::PasteParagraph() [paragraph.C:1612]
}
// delete the next paragraph
=> delete the_next;
}
cutSelection__11CutAndPasteP12LyXParagraphPP12LyXParagraphiRicb
[CutAndPaste.C:120]
startpar->Next()->ClearParagraph();
if
(startpar->FirstPhysicalPar()->HasSameLayout(startpar->Next()) ||
!startpar->Next()->Last())
=> startpar->ParFromPos(start)->PasteParagraph();
}
return true;
}
CutSelection__7LyXTextb [text2.C:2220]
cap.cutSelection(sel_start_cursor.par, &endpar,
Re: Core dump in 1.1.5cvs
On 20-Apr-2000 Jean-Marc Lasgouttes wrote: > > There is still a problem when cutting multiple paragraphs. If I create > a document with two paragraphs and try to cut them, I get a Free > Memory Read from purify (log follows). I do not know the code very > well, so I don't know what to do now. Note that the first trace from > purify is probably wrong (does not make sense) so the problems > probably happens in CutAndPaste.C. The problems does not happen when > disabling Juergen's new cap code. > Well I don't know if you're completely right. I controled the code in CutAndPaste.C line per line and I do exactly the same as in the old code (still in text2.C::CutSelection(...)). I see that there is a problem I just cannot see that I introduced it. For me it was there already before, what is strange obviously is that you cannot reproduce this with the new code disabled, could it be because I pass endpar back to the calling function while before all of that was in the same function? Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug The real reason large families benefit society is because at least a few of the children in the world shouldn't be raised by beginners. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Core dump in 1.1.5cvs
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> Well I don't know if you're completely right. I controled the Juergen> code in CutAndPaste.C line per line and I do exactly the same Juergen> as in the old code (still in text2.C::CutSelection(...)). I Juergen> see that there is a problem I just cannot see that I Juergen> introduced it. For me it was there already before, what is Juergen> strange obviously is that you cannot reproduce this with the Juergen> new code disabled, could it be because I pass endpar back to Juergen> the calling function while before all of that was in the same Juergen> function? I am currently trying to get a non-broken trace from purify to find out where the deleted memory is actually read. As it is now its a bit difficult to find out. JMarc
Re: Core dump in 1.1.5cvs
> The problem does not seem to depend on whether the paragraphs are > first/last in the document or not. Can't we switch from the current handcrafted list of paragraphs to some stl container (a list or rope e.g.) rather soon now? I have the suspicion that most of the current stability problems would simply vanish... Well... I do not trust anybody's STL implementation, but I trust LyX's heritage even less and sometimes I believe in Santa Claus ;-) Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: Core dump in 1.1.5cvs
On 20-Apr-2000 Andre Poenitz wrote: > > Can't we switch from the current handcrafted list of paragraphs to > some stl container (a list or rope e.g.) rather soon now? > No we should wait till we removed the floats (DUMMY paragraphs) after that it should be quite easy :) > > Well... I do not trust anybody's STL implementation, but I trust > LyX's heritage even less and sometimes I believe in Santa Claus ;-) You too believe in Santa Claus and I thought I would be the only one ;^) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug I Know A Joke!! -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: Core dump in 1.1.5cvs
Andre Poenitz <[EMAIL PROTECTED]> writes:
| > The problem does not seem to depend on whether the paragraphs are
| > first/last in the document or not.
|
| Can't we switch from the current handcrafted list of paragraphs to
| some stl container (a list or rope e.g.) rather soon now?
The problem with this rewrite is that it will be _huge_ (currently)
all code that looks at more than one paragaph expect struct par { par
* next}; and use it some hundreds of algorithms I guess...
So we try to do some cleanup first and move stuff out of LyXText (and
perhaps out of LyXParagraph too) before we make the paragraph list
into som e stl container.
| I have the suspicion that most of the current stability problems
| would simply vanish...
I would not be surprised...
| Well... I do not trust anybody's STL implementation, but I trust
| LyX's heritage even less and sometimes I believe in Santa Claus ;-)
:-)
Lgb
Re: Core dump on startup revistited
Compiled again now that Jean-Marc has submitted Dekel's combox patch. Can report that all is fine. No core dumps. Lyx is working again ;-) The question still remains however: why are the last few lines of language.C needed? static LangInit langinit; bool LangInit::init = false; Angus
Re: Core dump on startup revistited
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Compiled again now that Jean-Marc has submitted Dekel's combox Angus> patch. Can report that all is fine. No core dumps. Lyx is Angus> working again ;-) Angus> The question still remains however: why are the last few lines Angus> of language.C needed? Angus> static LangInit langinit; Angus> bool LangInit::init = false; It is a bool telling whether the initialization of languages has been done already, I guess. JMarc
Re: Core dump on startup revistited
> Angus> The question still remains however: why are the last few lines > Angus> of language.C needed? > > Angus> static LangInit langinit; > Angus> bool LangInit::init = false; > > It is a bool telling whether the initialization of languages has been > done already, I guess. Sorry, I didn't make myself clear. What I meant was, why does this static variable exist at all? It has scope only within the file and does nothing here other than initialise class static variable LangInit::init to true. Thereafter, this variable is reset to false. Why can't we get rid of "static LangInit langinit;" ? Or am I misreading this code? Angus
Re: Core dump on startup revistited
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> The question still remains however: why are the last few lines Angus> of language.C needed? >> Angus> static LangInit langinit; bool LangInit::init = false; >> It is a bool telling whether the initialization of languages has >> been done already, I guess. Angus> Sorry, I didn't make myself clear. What I meant was, why does Angus> this static variable exist at all? It has scope only within the Angus> file and does nothing here other than initialise class static Angus> variable LangInit::init to true. Thereafter, this variable is Angus> reset to false. Why can't we get rid of "static LangInit Angus> langinit;" ? I have to admit that I do not know, in fact. Lars? JMarc
Re: Core dump on startup revistited
Angus Leeming <[EMAIL PROTECTED]> writes: | > Angus> The question still remains however: why are the last few lines | > Angus> of language.C needed? | > | > Angus> static LangInit langinit; | > Angus> bool LangInit::init = false; | > | > It is a bool telling whether the initialization of languages has been | > done already, I guess. | | Sorry, I didn't make myself clear. What I meant was, why does this static | variable exist at all? It has scope only within the file and does nothing | here other than initialise class static variable LangInit::init to true. | Thereafter, this variable is reset to false. Why can't we get rid of | "static LangInit langinit;" ? It make the LangInit::LangInit constructor be run before main is started by the runtime environment. The errors you are seeing your be a problem with ordering of initializatoin of static global variables. Feel free to rewrite this is a lazy singleton class. Lgb
Re: Core dump when setting preferences with Lyx 1.1.6pre2
How about running reconfigure automatically if a user clicks preferences and no preferences file is found? Garst Ben Cazzolato wrote: > > Mon, 27 Nov 2000 > > Hi Guys > I am starting to use the pre-release of Lyx 1.1.6pre2 (downloaded RPM from > ftp://ftp.sylvan.com/pub/lyx/) and I can get Lyx to core dump every time. > > I tried Edit->Preferences immediately after upgrading from 1.5.2 (without > opening up Lyx first and reconfiguring) and it would crash every time. > > lyx: SIGSEGV signal caught > Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' > under the Help menu and then send us a full bug report. Thanks! > Bye. > Aborted (core dumped) > > I then did as Angus suggested, ie > > 1. Open up LyX and Edit->Reconfigure. > > 2. Close LyX. > > 3. Open up LyX again. > > > > Many of these warnings will dissapear. > > > > Your lyxrc is soon to become redundant. Open up Edit->Preferences, make some > > spurious change (to activate the Save button) and Save the change. You''ll > > now have a preferences file in your .lyx directory. lycrc will never be read > > again; instead preferences will be used instead. In future, use the > > Edit->Preferences popup to make any changes to LyX's behaviour. > > And all seems to be well. > > Maybe there needs to be some check for people like myself who will do things > without reading the instructions. > > Ben
Re: Core dump when setting preferences with Lyx 1.1.6pre2
On Sat, 2 Dec 2000, Garst R. Reese wrote: > How about running reconfigure automatically if a user clicks preferences > and no preferences file is found? > Garst This shouldn't make any difference to the operation of the Preferences dialog.The reconfigure simply updates lyxrc to the current keywords and thereby removes the warnings about unknown tags in lyxrc. Those are ingored anyway and have no effect upon LyX or the Preferences dialog. > Ben Cazzolato wrote: > > > > Mon, 27 Nov 2000 > > > > Hi Guys > > I am starting to use the pre-release of Lyx 1.1.6pre2 (downloaded RPM from > > ftp://ftp.sylvan.com/pub/lyx/) and I can get Lyx to core dump every time. > > > > I tried Edit->Preferences immediately after upgrading from 1.5.2 (without > > opening up Lyx first and reconfiguring) and it would crash every time. > > > > lyx: SIGSEGV signal caught > > Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' > > under the Help menu and then send us a full bug report. Thanks! > > Bye. > > Aborted (core dumped) Can you provide a backtrace of the core dump? Or details of what you were trying to change in Preferences when the core dump occured? I have noticed two crashes with current cvs yesterday while setting colours in Preferences. I haven't investigated these yet because Angus has another patch pending that changes most of this code. FWIW, both occured when applying a change to a GUI_Xxxx colour. A segfault occured in a signal/slot call (redrawGUI? I couldn't tell from the backtrace) while the other was an X BadDrawable error that killed LyX without a core dump. Allan. (ARRae) P.S. Ben are you going to the Linux Conference in Sydney in January?
Re: Core dump when setting preferences with Lyx 1.1.6pre2
> Can you provide a backtrace of the core dump? Or details of what you were > trying to change in Preferences when the core dump occured? Ummm, it's a bit late for that since the core file has been deleted! I guess I could delete the preferences file but don't think it'll be much help since I am not running the gdb option (as far as I know anyway). > I have noticed two crashes with current cvs yesterday while setting > colours in Preferences. I haven't investigated these yet because Angus > has another patch pending that changes most of this code. FWIW, both > occured when applying a change to a GUI_Xxxx colour. A segfault occured > in a signal/slot call (redrawGUI? I couldn't tell from the backtrace) > while the other was an X BadDrawable error that killed LyX without a core > dump. > > Allan. (ARRae) > > P.S. Ben are you going to the Linux Conference in Sydney in January? Love to but have just started a new job and it looks like things are going to be a little busy! I guess that means you are then?
Re: Core dump when setting preferences with Lyx 1.1.6pre2
On Sun, 3 Dec 2000, Ben Cazzolato wrote: [...] > > P.S. Ben are you going to the Linux Conference in Sydney in January? > > Love to but have just started a new job and it looks like things are going to > be a little busy! > > I guess that means you are then? Yes, although I haven't actually made any travel plans yet. Allan. (ARRae)
Re: Core dump when setting preferences with Lyx 1.1.6pre2
Errr Let's get this straight. Before you Reconfigured, you couldn't open Edit->Preferences. After you reconfigured you could. But isn't LyX reconfigured as part of thr installation process Don't understand. Angus On Sunday 03 December 2000 02:01, Ben Cazzolato wrote: > Mon, 27 Nov 2000 > > Hi Guys > I am starting to use the pre-release of Lyx 1.1.6pre2 (downloaded RPM from > ftp://ftp.sylvan.com/pub/lyx/) and I can get Lyx to core dump every time. > > I tried Edit->Preferences immediately after upgrading from 1.5.2 (without > opening up Lyx first and reconfiguring) and it would crash every time. > > lyx: SIGSEGV signal caught > Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' > under the Help menu and then send us a full bug report. Thanks! > Bye. > Aborted (core dumped) > > > I then did as Angus suggested, ie > > > 1. Open up LyX and Edit->Reconfigure. > > 2. Close LyX. > > 3. Open up LyX again. > > > > Many of these warnings will dissapear. > > > > Your lyxrc is soon to become redundant. Open up Edit->Preferences, make > > some spurious change (to activate the Save button) and Save the change. > > You''ll now have a preferences file in your .lyx directory. lycrc will > > never be read again; instead preferences will be used instead. In future, > > use the Edit->Preferences popup to make any changes to LyX's behaviour. > > And all seems to be well. > > Maybe there needs to be some check for people like myself who will do > things without reading the instructions. > > Ben
Re: Core dump when setting preferences with Lyx 1.1.6pre2
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Errr Let's get this straight. Before you Reconfigured, you Angus> couldn't open Edit-> Preferences. After you reconfigured you could. Angus> But isn't LyX reconfigured as part of thr installation Angus> process When installing, the system lyxrc.default is changed. What Reconfigure does is to change the user lyxrc.default. JMarc
Re: Core dump when setting preferences with Lyx 1.1.6pre2
Well how about adding a flag to the system lyxrc.defaults. \user_reconfigure yes/no ??? Angus On Monday 04 December 2000 11:11, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Errr Let's get this straight. Before you Reconfigured, you > Angus> couldn't open > Edit-> Preferences. After you reconfigured you could. > > Angus> But isn't LyX reconfigured as part of thr installation > Angus> process > > When installing, the system lyxrc.default is changed. What Reconfigure > does is to change the user lyxrc.default. > > JMarc
Re: Core dump when setting preferences with Lyx 1.1.6pre2
I guess that what is needed is a permanent entry in the system lyxrc.defaults \user_reconfigure 1.1.6 yes that is overridden by the corresponding entry in the user lyxrc.defaults \user_reconfigure 1.1.6 no Angus On Monday 04 December 2000 11:26, Angus Leeming wrote: > Well how about adding a flag to the system lyxrc.defaults. > > \user_reconfigure yes/no > > ??? > > Angus > > On Monday 04 December 2000 11:11, Jean-Marc Lasgouttes wrote: > > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > > > Angus> Errr Let's get this straight. Before you Reconfigured, you > > Angus> couldn't open > > Edit-> Preferences. After you reconfigured you could. > > > > Angus> But isn't LyX reconfigured as part of thr installation > > Angus> process > > > > When installing, the system lyxrc.default is changed. What Reconfigure > > does is to change the user lyxrc.default. > > > > JMarc
Re: Core dump when setting preferences with Lyx 1.1.6pre2
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> I guess that what is needed is a permanent entry in the system Angus> lyxrc.defaults \user_reconfigure 1.1.6 yes Angus> that is overridden by the corresponding entry in the user Angus> lyxrc.defaults Angus> \user_reconfigure 1.1.6 no Or rather a way to see when configure was run for the last time, so that it can be automatically re-run if necessary (\last_configure_version 1.1.6) Anyway, no crash should happen! JMarc
Re: Core dump when setting preferences with Lyx 1.1.6pre2
On Monday 04 December 2000 11:41, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> I guess that what is needed is a permanent entry in the system > Angus> lyxrc.defaults \user_reconfigure 1.1.6 yes > > Angus> that is overridden by the corresponding entry in the user > Angus> lyxrc.defaults > > Angus>\user_reconfigure 1.1.6 no > > Or rather a way to see when configure was run for the last time, so > that it can be automatically re-run if necessary > (\last_configure_version 1.1.6) Good. > Anyway, no crash should happen! Well, I can''t reproduce this: lyx-1.1.4, Reconfigure, Close. mv ~/.lyx/preferences ~/.lyx/preferences_safe lyx-1.1.6cvs, Edit->Preferences No crash. Don't see how we can find the root cause of the problem, therefore. Your suggested work around seems like the best way forward. Angus
Re: Core dump when setting preferences with Lyx 1.1.6pre2
Angus Leeming <[EMAIL PROTECTED]> writes: | Errr | | Let's get this straight. Before you Reconfigured, you couldn't open | Edit->Preferences. After you reconfigured you could. Why does this make a difference? It really shouldn't. Lgb
Re: Core dump when setting preferences with Lyx 1.1.6pre2
Angus Leeming <[EMAIL PROTECTED]> writes: | > Anyway, no crash should happen! | | Well, I can''t reproduce this: | | lyx-1.1.4, Reconfigure, Close. | mv ~/.lyx/preferences ~/.lyx/preferences_safe | lyx-1.1.6cvs, Edit->Preferences | | No crash. Don't see how we can find the root cause of the problem, therefore. | Your suggested work around seems like the best way forward. I don't really like to use work arounds for problems we don't understand. The best way forward is to find out _why_ lyx craches and fix that reason or the wrong assumtions in the code. Everything else will just at bloat and complexity. Lgb
Re: Core dump when setting preferences with Lyx 1.1.6pre2
Guys > Errr > > Let's get this straight. Before you Reconfigured, you couldn't open > Edit->Preferences. After you reconfigured you could. Before manually reconfiguring I could open up the Preferences but it would cause the crash. Yes, when lyx is installing it runs reconfigure. However, I presume the problem arose cause I installed as root, so the automatic reconfigure would have been for root, would it not? After I ran reconfigure manually the crash no longer appeared. That would also explain why when I ran lyx from a terminal window I got buckets of warning about my lyxrc file. Does this help? Ben > But > isn't LyX reconfigured as part of thr installation process > > Don't understand. > > Angus >
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> Create an inset, and an inset inside it, and copy/paste the second one
> to somewhere else inside the first. Then try to exit. LyX will core
> dump. (Not if either source or target inset are outside the first
> inset.)
All seems fine here. Could you be more precise. What insets did you use?
> Backtrace (sorry, no debug info):
>
> #0 0x40266d41 in __kill () from /lib/libc.so.6
> #1 0x402669b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
> #2 0x402680d8 in abort () at ../sysdeps/generic/abort.c:88
> #3 0x84d2317 in lyx::support::abort ()
> #4 0x8122536 in error_handler ()
> #5 0x40266c68 in __restore ()
> at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
> #6 0x818bebe in Messages::get ()
> #7 0x80fb794 in _ ()
> #8 0x82e29b8 in Dialogs::build ()
> #9 0x82c4ab5 in Dialogs::find ()
> #10 0x82c5021 in Dialogs::hideSlot ()
Maybe add some print statements to this. What is "name"? Was the dialog open
at the time?
void Dialogs::hideSlot(string const & name, InsetBase * inset)
{
Dialog * dialog = find(name);
if (!dialog)
return;
if (inset && inset != getOpenInset(name))
return;
if (dialog->isVisible())
dialog->hide();
open_insets_[name] = 0;
}
Nonetheless, it is pretty crappy that we try and 'build' a dialog on 'hide'...
--
Angus
Re: Core dump on exit after pasting inset in inset
On Mon, Sep 15, 2003 at 04:28:45PM +, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
>
> > Create an inset, and an inset inside it, and copy/paste the second one
> > to somewhere else inside the first. Then try to exit. LyX will core
> > dump. (Not if either source or target inset are outside the first
> > inset.)
>
> All seems fine here. Could you be more precise. What insets did you use?
As follows:
1) create a footnote inset.
2) create a minipage inset inside it.
3) close it by clicking button.
4) paint it to select
5) choose "copy" from menu
6) place cursor after it
7) choose "paste" from menu
8) now you should have two closed minipages side by side in the
footnote.
9) Exit, discard document.
It works just as well if you put two comment or greyedout insets inside
a note inset. Or whatever. It isn't exactly hard :-(
> > Backtrace (sorry, no debug info):
> >
> > #0 0x40266d41 in __kill () from /lib/libc.so.6
> > #1 0x402669b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
> > #2 0x402680d8 in abort () at ../sysdeps/generic/abort.c:88
> > #3 0x84d2317 in lyx::support::abort ()
> > #4 0x8122536 in error_handler ()
> > #5 0x40266c68 in __restore ()
> > at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
> > #6 0x818bebe in Messages::get ()
> > #7 0x80fb794 in _ ()
> > #8 0x82e29b8 in Dialogs::build ()
> > #9 0x82c4ab5 in Dialogs::find ()
> > #10 0x82c5021 in Dialogs::hideSlot ()
>
> Maybe add some print statements to this. What is "name"? Was the dialog open
> at the time?
No, it was not.
> void Dialogs::hideSlot(string const & name, InsetBase * inset)
> {
> Dialog * dialog = find(name);
> if (!dialog)
> return;
>
> if (inset && inset != getOpenInset(name))
> return;
>
> if (dialog->isVisible())
> dialog->hide();
> open_insets_[name] = 0;
> }
>
> Nonetheless, it is pretty crappy that we try and 'build' a dialog on 'hide'...
I was amazed to see the backtrace.
> --
> Angus
>
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
On Mon, Sep 15, 2003 at 04:28:45PM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
>
> > Create an inset, and an inset inside it, and copy/paste the second one
> > to somewhere else inside the first. Then try to exit. LyX will core
> > dump. (Not if either source or target inset are outside the first
> > inset.)
>
> All seems fine here. Could you be more precise. What insets did you use?
OK, the "inside" insets have to be insets *with* a dialog, e.g.
minipage. Footnote won't do.
> > Backtrace (sorry, no debug info):
> >
> > #0 0x40266d41 in __kill () from /lib/libc.so.6
> > #1 0x402669b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
> > #2 0x402680d8 in abort () at ../sysdeps/generic/abort.c:88
> > #3 0x84d2317 in lyx::support::abort ()
> > #4 0x8122536 in error_handler ()
> > #5 0x40266c68 in __restore ()
> > at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
> > #6 0x818bebe in Messages::get ()
> > #7 0x80fb794 in _ ()
> > #8 0x82e29b8 in Dialogs::build ()
> > #9 0x82c4ab5 in Dialogs::find ()
> > #10 0x82c5021 in Dialogs::hideSlot ()
>
> Maybe add some print statements to this. What is "name"? Was the dialog open
> at the time?
I did that at the start.
It prints "minipage" four times if that's the two inside a footnote.
If you put two footnotes inside a minipage, you get three times
"minipage" but no segfault.
> void Dialogs::hideSlot(string const & name, InsetBase * inset)
> {
> Dialog * dialog = find(name);
> if (!dialog)
> return;
>
> if (inset && inset != getOpenInset(name))
> return;
>
> if (dialog->isVisible())
> dialog->hide();
> open_insets_[name] = 0;
> }
Digging on. -M
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> On Mon, Sep 15, 2003 at 04:28:45PM +, Angus Leeming spake thusly:
>>
>> Martin Vermeer wrote:
>>
>> > Create an inset, and an inset inside it, and copy/paste the second one
>> > to somewhere else inside the first. Then try to exit. LyX will core
>> > dump. (Not if either source or target inset are outside the first
>> > inset.)
>>
>> All seems fine here. Could you be more precise. What insets did you use?
>
> As follows:
[snip...]
I have followed your prescription exactly. Nada.
>> > Backtrace (sorry, no debug info):
>> > #0 0x40266d41 in __kill () from /lib/libc.so.6
>> > #1 0x402669b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
>> > #2 0x402680d8 in abort () at ../sysdeps/generic/abort.c:88
>> > #3 0x84d2317 in lyx::support::abort ()
>> > #4 0x8122536 in error_handler ()
>> > #5 0x40266c68 in __restore ()
>> > at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
>> > #6 0x818bebe in Messages::get ()
>> > #7 0x80fb794 in _ ()
>> > #8 0x82e29b8 in Dialogs::build ()
>> > #9 0x82c4ab5 in Dialogs::find ()
>> > #10 0x82c5021 in Dialogs::hideSlot ()
>>
>> Maybe add some print statements to this. What is "name"? Was the dialog
>> open at the time?
> No, it was not.
Could you perhaps compile src/messages.C with debug info.
$ touch src/messages.C
$ cd ${BUILDDIR}
$ make CXXFLAGS="-g -W -Wall"
Which particular flavour of messages.C do you use? (#ifdef ENABLE_NLS)
>> Nonetheless, it is pretty crappy that we try and 'build' a dialog on
>> 'hide'...
> I was amazed to see the backtrace.
Well, I have a patch for _that_ at least. First though, let's ascertain what
is going wrong.
--
Angus
Re: Core dump on exit after pasting inset in inset
On Mon, Sep 15, 2003 at 05:13:05PM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
...
> I have followed your prescription exactly. Nada.
...
> Could you perhaps compile src/messages.C with debug info.
> $ touch src/messages.C
> $ cd ${BUILDDIR}
> $ make CXXFLAGS="-g -W -Wall"
Did that. The interesting part of the backtrace:
---
#6 0x855e32a in basic_string,
__default_alloc_template >::terminate (this=0x87f82b0)
at
/usr/lib/gcc-lib/i386-conectiva-linux/2.95.3/../../../../include/g++-3/std/bastring.h:331
#7 0x855e19c in basic_string,
__default_alloc_template >::c_str (this=0x87f82b0)
at
/usr/lib/gcc-lib/i386-conectiva-linux/2.95.3/../../../../include/g++-3/std/bastring.h:335
#8 0x855df46 in Messages::Pimpl::get (this=0x87f82b0, [EMAIL PROTECTED])
at messages.C:112
#9 0x818caf2 in Messages::get (this=0x87ebff4, [EMAIL PROTECTED]) at
messages.C:159
#10 0x80fc984 in _ ()
#11 0x82e36f8 in Dialogs::build () at messages.C:160
#12 0x82c56f5 in Dialogs::find () at messages.C:160
#13 0x82c5ca3 in Dialogs::hideSlot () at messages.C:160
---
Messages::Pimpl::get:
106 string const get(string const & m) const
107 {
108 if (m.empty())
109 return m;
110
111 char * old = strdup(setlocale(LC_ALL, 0));
--> 112 char * n = setlocale(LC_ALL, lang_.c_str());
113 const char* msg = gettext(m.c_str());
114 setlocale(LC_ALL, old);
115 free(old);
116 // If we are unable to honour the request we just
117 // return what we got in.
118 return (!n ? m : string(msg));
119 }
WTF?
> Which particular flavour of messages.C do you use? (#ifdef ENABLE_NLS)
Apparently ENABLE_NLS is true.
> >> Nonetheless, it is pretty crappy that we try and 'build' a dialog on
> >> 'hide'...
> > I was amazed to see the backtrace.
>
> Well, I have a patch for _that_ at least. First though, let's ascertain what
> is going wrong.
>
> --
> Angus
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Mon, Sep 15, 2003 at 05:13:05PM +, Angus Leeming spake thusly:
|
>> Martin Vermeer wrote:
>
| ...
|
>> I have followed your prescription exactly. Nada.
>
| ...
|
>> Could you perhaps compile src/messages.C with debug info.
>> $ touch src/messages.C
>> $ cd ${BUILDDIR}
>> $ make CXXFLAGS="-g -W -Wall"
>
| Did that. The interesting part of the backtrace:
>
Stuff like this can be hard to debug, and if you are using the
debugger you have to compile without optimization, and preferably with
inlining turned off.
-O0 -fno-inline -fno-default-inline
Please try this.
--
Lgb
Re: Core dump on exit after pasting inset in inset
Lars Gullik Bjønnes wrote:
>>> Could you perhaps compile src/messages.C with debug info.
>>> $ touch src/messages.C
>>> $ cd ${BUILDDIR}
>>> $ make CXXFLAGS="-g -W -Wall"
>>
> | Did that. The interesting part of the backtrace:
>>
> Stuff like this can be hard to debug, and if you are using the
> debugger you have to compile without optimization, and preferably with
> inlining turned off.
>
> -O0 -fno-inline -fno-default-inline
> Please try this.
Is it not sufficient to compile the file that is causing the SIGSEGV in this
way? If so, then the prescription above should be enough, no?
--
Angus
Re: Core dump on exit after pasting inset in inset
On Mon, Sep 15, 2003 at 05:33:41PM +, Angus Leeming spake thusly:
> Lars Gullik Bjønnes wrote:
> >>> Could you perhaps compile src/messages.C with debug info.
> >>> $ touch src/messages.C
> >>> $ cd ${BUILDDIR}
> >>> $ make CXXFLAGS="-g -W -Wall"
> >>
> > | Did that. The interesting part of the backtrace:
> >>
> > Stuff like this can be hard to debug, and if you are using the
> > debugger you have to compile without optimization, and preferably with
> > inlining turned off.
> >
> > -O0 -fno-inline -fno-default-inline
> > Please try this.
>
> Is it not sufficient to compile the file that is causing the SIGSEGV in this
> way? If so, then the prescription above should be enough, no?
>
> --
> Angus
I did that too (but only recompiling messages.C). Backtrace (partly):
---
#4 0x8123726 in error_handler ()
#5 0x40266c68 in __restore ()
at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#6 0x855e0e2 in basic_string,
__default_alloc_template >::terminate (this=0x87f8250)
at
/usr/lib/gcc-lib/i386-conectiva-linux/2.95.3/../../../../include/g++-3/std/bastring.h:331
#7 0x855e11c in basic_string,
__default_alloc_template >::c_str (this=0x87f8250)
at
/usr/lib/gcc-lib/i386-conectiva-linux/2.95.3/../../../../include/g++-3/std/bastring.h:335
#8 0x855e33e in Messages::Pimpl::get (this=0x87f8250, [EMAIL PROTECTED])
at messages.C:112
#9 0x818caf2 in Messages::get (this=0x87ebf94, [EMAIL PROTECTED])
at messages.C:159
#10 0x80fc984 in _ ()
#11 0x82e36f8 in Dialogs::build () at messages.C:160
#12 0x82c56f5 in Dialogs::find () at messages.C:160
#13 0x82c5ca3 in Dialogs::hideSlot () at messages.C:160
---
I believe the line numbers 159 and 112 are realistic. messages.C:160
is not (These "phantom locations" are often seen for files not
compiled with debug instrumentation.)
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
>> Is it not sufficient to compile the file that is causing the SIGSEGV in
>> this way? If so, then the prescription above should be enough, no?
>>
> I did that too (but only recompiling messages.C). Backtrace (partly):
>
> ---
> #4 0x8123726 in error_handler ()
> #5 0x40266c68 in __restore ()
> at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
> #6 0x855e0e2 in basic_string,
> __default_alloc_template >::terminate (this=0x87f8250)
> at
>
/usr/lib/gcc-lib/i386-conectiva-linux/2.95.3/../../../../include/g++-3/std/bastring.h:331
> #7 0x855e11c in basic_string,
> __default_alloc_template >::c_str (this=0x87f8250)
> at
>
/usr/lib/gcc-lib/i386-conectiva-linux/2.95.3/../../../../include/g++-3/std/bastring.h:335
> #8 0x855e33e in Messages::Pimpl::get (this=0x87f8250, [EMAIL PROTECTED])
> at messages.C:112
> #9 0x818caf2 in Messages::get (this=0x87ebf94, [EMAIL PROTECTED])
> at messages.C:159
> #10 0x80fc984 in _ ()
> #11 0x82e36f8 in Dialogs::build () at messages.C:160
> #12 0x82c56f5 in Dialogs::find () at messages.C:160
> #13 0x82c5ca3 in Dialogs::hideSlot () at messages.C:160
> ---
>
> I believe the line numbers 159 and 112 are realistic. messages.C:160
> is not (These "phantom locations" are often seen for files not
> compiled with debug instrumentation.)
Ok, it looks to me like that 'lang_' member variable has been corrupted.
Do you have LANG and LC_ALL environment variables set? Here I have
$ echo "LANG=\"$LANG\" LC_ALL=\"$LC_ALL\""
LANG="en_US" LC_ALL=""
What does valgrind say if you run lyx through that?
Just in case you would prefer to do some work with 14x, here is a patch that
should 'cure' the problem, but only by hiding it. I'd prefer to get to the
bottom of this first.
--
AngusIndex: src/frontends/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/ChangeLog,v
retrieving revision 1.225
diff -u -p -r1.225 ChangeLog
--- src/frontends/ChangeLog 15 Sep 2003 15:20:16 - 1.225
+++ src/frontends/ChangeLog 15 Sep 2003 20:47:46 -
@@ -1,5 +1,12 @@
2003-09-15 Angus Leeming <[EMAIL PROTECTED]>
+ * Dialogs.[Ch] (find): renamed as find_or_build.
+ (update, hideSlot): don't call find_or_build to find the requested dialog.
+ Instead, search dialogs_, the list of already constructed dialogs. If it
+ ain't found, do nothing.
+
+2003-09-15 Angus Leeming <[EMAIL PROTECTED]>
+
* Painter.C: add #include "LColor.h".
(rectText): pass EnumLColor args, rather than LColor::color ones.
Index: src/frontends/Dialogs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/Dialogs.C,v
retrieving revision 1.28
diff -u -p -r1.28 Dialogs.C
--- src/frontends/Dialogs.C 5 Sep 2003 10:55:42 - 1.28
+++ src/frontends/Dialogs.C 15 Sep 2003 20:47:46 -
@@ -75,7 +75,7 @@ Dialogs::Dialogs(LyXView & lyxview)
}
-Dialog * Dialogs::find(string const & name)
+Dialog * Dialogs::find_or_build(string const & name)
{
if (!isValidName(name))
return 0;
@@ -83,18 +83,17 @@ Dialog * Dialogs::find(string const & na
std::map::iterator it =
dialogs_.find(name);
- if (it == dialogs_.end()) {
- dialogs_[name] = DialogPtr(build(name));
- return dialogs_[name].get();
- }
+ if (it != dialogs_.end())
+ return it->second.get();
- return it->second.get();
+ dialogs_[name] = DialogPtr(build(name));
+ return dialogs_[name].get();
}
void Dialogs::show(string const & name, string const & data)
{
- Dialog * dialog = find(name);
+ Dialog * dialog = find_or_build(name);
if (!dialog)
return;
@@ -105,7 +104,7 @@ void Dialogs::show(string const & name,
void Dialogs::show(string const & name, string const & data, InsetBase * inset)
{
- Dialog * dialog = find(name);
+ Dialog * dialog = find_or_build(name);
if (!dialog)
return;
@@ -127,10 +126,12 @@ bool Dialogs::visible(string const & nam
void Dialogs::update(string const & name, string const & data)
{
- Dialog * dialog = find(name);
- if (!dialog)
+ std::map::const_iterator it =
+ dialogs_.find(name);
+ if (it == dialogs_.end())
return;
+ Dialog * const dialog = it->second.get();
if (dialog->isVisible())
dialog->update(data);
}
@@ -138,13 +139,15 @@ void Dialogs::update(string const & name
void Dialogs::hideSlot(string const & name, InsetBase * inset)
{
- Dialog * dialog = find(name);
- if (!dialog)
+ std::map::const_iterator it =
+ dialogs_.find(name);
+ if (it == dialogs_.end())
return;
if (inset && inset != getOpenInset(name))
return;
+ Dialog * const dialog = it->second.get();
if (dialog->isVisible())
dialog->hide();
open_insets_[name] = 0;
Index: src/frontends/Dialogs.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/Dialogs.h,v
retrieving revision 1.90
diff -u -p -r1.90 Dialogs.h
--- src/frontends/Dialogs.h 7 Sep 2003 21:
Re: Core dump on exit after pasting inset in inset
On Mon, Sep 15, 2003 at 09:56:22PM +, Angus Leeming spake thusly: > > Martin Vermeer wrote: > >> Is it not sufficient to compile the file that is causing the SIGSEGV in > >> this way? If so, then the prescription above should be enough, no? > >> > > I did that too (but only recompiling messages.C). Backtrace (partly): ... > Ok, it looks to me like that 'lang_' member variable has been corrupted. That is possible. If so, let's find out where. What does surprise me is that this should happen only as a result of pasting an inset into another inset. The exact same document on-screen created without that paste does *not* core dump. (Apparently it is not the same in-memory doc.) > Do you have LANG and LC_ALL environment variables set? Here I have > $ echo "LANG=\"$LANG\" LC_ALL=\"$LC_ALL\"" > LANG="en_US" LC_ALL="" Exactly the same here. > What does valgrind say if you run lyx through that? Don't have a working valgrind installed right now. > Just in case you would prefer to do some work with 14x, here is a patch that > should 'cure' the problem, but only by hiding it. I'd prefer to get to the > bottom of this first. Hmmm no, I don't do production work on 1.4x. And yes, we should get to the bottom of this. > -- > Angus Martin pgp0.pgp Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
Could you perhaps compile src/messages.C with debug info.
$ touch src/messages.C
$ cd ${BUILDDIR}
$ make CXXFLAGS="-g -W -Wall"
>>>
>> | Did that. The interesting part of the backtrace:
>>>
>> Stuff like this can be hard to debug, and if you are using the
>> debugger you have to compile without optimization, and preferably with
>> inlining turned off.
>>
>> -O0 -fno-inline -fno-default-inline
>> Please try this.
>
| Is it not sufficient to compile the file that is causing the SIGSEGV in this
| way? If so, then the prescription above should be enough, no?
Perhaps, but you will easily get fooled by inlining.
-g is not enough.
--
Lgb
Re: Core dump on exit after pasting inset in inset
On Mon, Sep 15, 2003 at 09:56:22PM +, Angus Leeming spake thusly:
...
> Ok, it looks to me like that 'lang_' member variable has been corrupted.
> Do you have LANG and LC_ALL environment variables set? Here I have
> $ echo "LANG=\"$LANG\" LC_ALL=\"$LC_ALL\""
> LANG="en_US" LC_ALL=""
>
> What does valgrind say if you run lyx through that?
...
> --
> Angus
Here's the valgrind output. Yes, it seems there is a problem with
lang_, specifically the creation of lang_.c_str().
==10981==
==10981== Invalid write of size 1
==10981==at 0x4042E17B: string_char_traits::assign(char &,
char const &) (in /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so)
==10981==by 0x855DF4B: basic_string,
__default_alloc_template >::c_str(void) const
>(/usr/lib/gcc-lib/i386-conectiva-linux/2.95.3/../../../../include/g++-3/std/bastring.h:335)
==10981==by 0x855DCF5: Messages::Pimpl::get(basic_string, __default_alloc_template > const &)
const (messages.C:112)
==10981==by 0x818CDF1: Messages::get(basic_string, __default_alloc_template > const &)
const (messages.C:159)
==10981==Address 0x84378154 is not stack'd, malloc'd or free'd
This refers to the calling of the .c_str() method in bastring.h, and
within that, the calling of terminate(), which calls traits::assign
like:
private:
void terminate () const
{ traits::assign ((*rep ())[length ()], eos ()); }
I suspect that for whatever reason this assignment goes into the blue.
(I tried to add lyxerr's to message.C, but then it already segfaults at
startup. There is something fishy going on.)
- Martin
==10981== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==10981== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==10981== Using valgrind-20030725, a program supervision framework for x86-linux.
==10981== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==10981== Estimated CPU clock rate is 398 MHz
==10981== For more details, rerun with: -v
==10981==
==10981== Source and destination overlap in strncpy(0x4031c890, 0x4031c890, 20)
==10981==at 0x40021335: strncpy (in
/home/mv/valgrind/lib/valgrind/vgskin_memcheck.so)
==10981==by 0x402CC422: fl_get_resource (in
/home/mv/xforms-cvs/build/test-install/lib/libforms.so.1.0.0)
==10981==by 0x402CD70B: get_app_resource (in
/home/mv/xforms-cvs/build/test-install/lib/libforms.so.1.0.0)
==10981==by 0x402CD756: fl_get_app_resources (in
/home/mv/xforms-cvs/build/test-install/lib/libforms.so.1.0.0)
==10981==
==10981== Source and destination overlap in strncpy(0x4031c890, 0x4031c890, 20)
==10981==at 0x40021335: strncpy (in
/home/mv/valgrind/lib/valgrind/vgskin_memcheck.so)
==10981==by 0x402CC422: fl_get_resource (in
/home/mv/xforms-cvs/build/test-install/lib/libforms.so.1.0.0)
==10981==by 0x402CD70B: get_app_resource (in
/home/mv/xforms-cvs/build/test-install/lib/libforms.so.1.0.0)
==10981==by 0x402CD774: fl_get_app_resources (in
/home/mv/xforms-cvs/build/test-install/lib/libforms.so.1.0.0)
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
lyxlex: UNcompressed
text not available!
no text in cache!
branch not collapsed_
branch not collapsed_
InsetText::lockInsetInInset: 1 a
InsetText::lockInsetInInset: 1 b
bv: 0x42e97d00 inset: 0x422560c0
InsetText::lockInsetInInset: 1 c
==10981==
==10981== Conditional jump or move depends on uninitialised value(s)
==10981==at 0x4038B677: GetLooseVEntry (in /usr/X11R6/lib/libX11.so.6.1)
==10981==by 0x4038B870: GetNEntry (in /usr/X11R6/lib/libX11.so.6.1)
==10981==by 0x4038BFEF: XrmQGetResource (in /usr/X11R6/lib/libX11.so.6.1)
==10981==by 0x4038C0DD: XrmGetResource (in /usr/X11R6/lib/libX11.so.6.1)
==10981==
==10981== Invalid read of size 4
==10981==at 0x858181F: _Rb_tree,
__default_alloc_template >, pair,
__default_alloc_template > const, boost::shared_ptr >,
_Select1st,
__default_alloc_template > const, boost::shared_ptr > >,
less, __default_alloc_template >
>, allocator > >::find(basic_strin
==10981==by 0x82C5729: Dialogs::find(basic_string,
__default_alloc_template > const &) (in /home/mv/lyx-cvs/src/lyx-xforms)
==10981==by 0x82C5E90: Dialogs::hideSlot(basic_string, __default_alloc_template > const &, InsetBase *)
(in /home/mv/lyx-cvs/src/lyx-xforms)
==10981==by 0x8582DF7:
boost::detail::function::void_function_obj_invoker2,
__default_alloc_template > const &, InsetBase *>,
boost::_bi::list3, boost::arg<1>, boost::arg<2> > >,
void, basic_string, __default_alloc_template >
const &, InsetBase *>::invoke(boost::detail::function::any_pointer, basic_string,
==10981==Address 0x42BA27FC i
Re: Core dump on exit after pasting inset in inset
On Mon, Sep 15, 2003 at 09:56:22PM +, Angus Leeming spake thusly: ... > What does valgrind say if you run lyx through that? ==10981==Address 0x421B6530 is 0 bytes inside a block of size 4 free'd ==10981==at 0x40028DF2: __builtin_delete (in /home/mv/valgrind/lib/valgrind/vgskin_memcheck.so) ==10981==by 0x855E11D: Messages::Pimpl::~Pimpl(void) (messages.C:104) ==10981==by 0x855DF88: void boost::checked_delete(Messages::Pimpl *) (../boost/boost/checked_delete.hpp:34) ==10981==by 0x855DDB8: boost::scoped_ptr::~scoped_ptr(void) (../boost/boost/scoped_ptr.hpp:78) H... is it possible that lang_ is being accessed after the containing class Messages::Pimpl has been destroyed? ... > Angus - Martin pgp0.pgp Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> H... is it possible that lang_ is being accessed after the
> containing class Messages::Pimpl has been destroyed?
If so, I guess that this is the kludge. Thereafter we'd have to
ascertain _why_?
string const Messages::get(string const & msg) const
{
return pimpl_.get() ? pimpl_->get(msg) : msg;
}
--
Angus
Re: Core dump on exit after pasting inset in inset
On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
> > H... is it possible that lang_ is being accessed after the
> > containing class Messages::Pimpl has been destroyed?
>
> If so, I guess that this is the kludge. Thereafter we'd have to
> ascertain _why_?
>
> string const Messages::get(string const & msg) const
> {
> return pimpl_.get() ? pimpl_->get(msg) : msg;
> }
>
> --
> Angus
Yes that should do the job... but.
I did a little further debugging by instrumenting messages.C as
follows:
107 string const get(string const & m) const
108 {
109 if (m.empty())
110 return m;
111
112 char * old = strdup(setlocale(LC_ALL, 0));
113 char * n;
114 if (lang_.size() < 100)
115 n = setlocale(LC_ALL, lang_.c_str());
116 else {
117 n = setlocale(LC_ALL, string("en_US").c_str());
118 lyxerr << "error:" << lang_.size() << " " << m << std::endl;
119 }
120 const char* msg = gettext(m.c_str());
121 setlocale(LC_ALL, old);
122 free(old);
123 // If we are unable to honour the request we just
124 // return what we got in.
125 return (!n ? m : string(msg));
126 }
Creating a Note inset, a Minipage inside it, and copying pasting the
latter, I get:
error:193248 Close
error:193248 Cancel
error:193248 Minipage Settings
(the number value doesn't change on recompile)
It turns out that the trouble is caused by three localized strings:
1) in frontends/xforms/dialogs.C the build() routine:
153 dialog->bc().view(new xformsBC(dialog->bc()));
The call to xformsBC has two default string parameters, see
frontends/xforms/xformsBC.h:
22 class xformsBC : public GuiBC {
23 public:
24 ///
25 xformsBC(ButtonController const &,
26 string const & = _("Cancel"), string const & = _("Close"));
...and then there are the Form*.C files, e.g. FormMinipage.C:
34 FormMinipage::FormMinipage(Dialog & parent)
35 : base_class(parent, _("Minipage Settings"))
36 {}
This is where the three strings come from.
Does this ring any bells?
But remember also that *pasting* the dialog'ed inset is mandatory to
get the invalid lang_. Create the same inset geometry the regular way
will *not* produce it.
BTW the above kludge does *not* work. No difference. So the
Messages::Pimpl instantiation is existing, but lang_ is messed up.
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
|
>> Martin Vermeer wrote:
>> > H... is it possible that lang_ is being accessed after the
>> > containing class Messages::Pimpl has been destroyed?
>>
>> If so, I guess that this is the kludge. Thereafter we'd have to
>> ascertain _why_?
>>
>> string const Messages::get(string const & msg) const
>> {
>> return pimpl_.get() ? pimpl_->get(msg) : msg;
>> }
And you are sure that this is what happens?
Do we have any static objects? (we shouldn't) Global objects?
| It turns out that the trouble is caused by three localized strings:
>
| 1) in frontends/xforms/dialogs.C the build() routine:
>
|153 dialog->bc().view(new xformsBC(dialog->bc()));
>
| The call to xformsBC has two default string parameters, see
| frontends/xforms/xformsBC.h:
>
| 22 class xformsBC : public GuiBC {
| 23 public:
| 24 ///
| 25 xformsBC(ButtonController const &,
| 26 string const & = _("Cancel"), string const & = _("Close"));
this is potentially bad... might be called too early.
| BTW the above kludge does *not* work. No difference. So the
| Messages::Pimpl instantiation is existing, but lang_ is messed up.
And the value of lang_?
--
Lgb
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 09:36:28AM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
> |
> >> Martin Vermeer wrote:
> >> > H... is it possible that lang_ is being accessed after the
> >> > containing class Messages::Pimpl has been destroyed?
> >>
> >> If so, I guess that this is the kludge. Thereafter we'd have to
> >> ascertain _why_?
> >>
> >> string const Messages::get(string const & msg) const
> >> {
> >> return pimpl_.get() ? pimpl_->get(msg) : msg;
> >> }
>
> And you are sure that this is what happens?
No...
> Do we have any static objects? (we shouldn't) Global objects?
Yes! in gettext.C:
24 Messages & getLyXMessages()
25 {
26 static Messages lyx_messages;
27
28 return lyx_messages;
29 }
30
31 } // anon namespace
> | It turns out that the trouble is caused by three localized strings:
> >
> | 1) in frontends/xforms/dialogs.C the build() routine:
> >
> |153 dialog->bc().view(new xformsBC(dialog->bc()));
> >
> | The call to xformsBC has two default string parameters, see
> | frontends/xforms/xformsBC.h:
> >
> | 22 class xformsBC : public GuiBC {
> | 23 public:
> | 24 ///
> | 25 xformsBC(ButtonController const &,
> | 26 string const & = _("Cancel"), string const & = _("Close"));
>
> this is potentially bad... might be called too early.
>
> | BTW the above kludge does *not* work. No difference. So the
> | Messages::Pimpl instantiation is existing, but lang_ is messed up.
>
> And the value of lang_?
From the first three bytes, I would say 0xff, 0xff, 0xff, ... in other
words, junk.
> --
> Lgb
>
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Do we have any static objects? (we shouldn't) Global objects?
>
| Yes! in gettext.C:
>
| 24 Messages & getLyXMessages()
| 25 {
| 26 static Messages lyx_messages;
| 27
| 28 return lyx_messages;
| 29 }
| 30
| 31 } // anon namespace
Well... that one should be ok...
| From the first three bytes, I would say 0xff, 0xff, 0xff, ... in other
| words, junk.
and in the shell? LANG LANGUAGE etc?
--
Lgb
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> Do we have any static objects? (we shouldn't) Global objects?
> >
> | Yes! in gettext.C:
> >
> | 24 Messages & getLyXMessages()
> | 25 {
> | 26 static Messages lyx_messages;
> | 27
> | 28 return lyx_messages;
> | 29 }
> | 30
> | 31 } // anon namespace
>
> Well... that one should be ok...
>
> | From the first three bytes, I would say 0xff, 0xff, 0xff, ... in other
> | words, junk.
>
> and in the shell? LANG LANGUAGE etc?
>
> --
> Lgb
LANG=en_US and the rest undefined.
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
>>
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> >> Do we have any static objects? (we shouldn't) Global objects?
>> >
>> | Yes! in gettext.C:
>> >
>> | 24 Messages & getLyXMessages()
>> | 25 {
>> | 26 static Messages lyx_messages;
>> | 27
>> | 28 return lyx_messages;
>> | 29 }
>> | 30
>> | 31 } // anon namespace
>>
>> Well... that one should be ok...
>>
>> | From the first three bytes, I would say 0xff, 0xff, 0xff, ... in other
>> | words, junk.
>>
>> and in the shell? LANG LANGUAGE etc?
If it is 0xff 0xff 0xff... then it looks like planned junk...
(all bits set)
--
Lgb
Re: Core dump on exit after pasting inset in inset
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Wed, Sep 17, 2003 at 10:21:54AM +0200, Lars Gullik Bjønnes spake thusly:
>>
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> >> Do we have any static objects? (we shouldn't) Global objects?
>> >
>> | Yes! in gettext.C:
>> >
>> | 24 Messages & getLyXMessages()
>> | 25 {
>> | 26 static Messages lyx_messages;
>> | 27
>> | 28 return lyx_messages;
>> | 29 }
>> | 30
>> | 31 } // anon namespace
>>
>> Well... that one should be ok...
>>
>> | From the first three bytes, I would say 0xff, 0xff, 0xff, ... in other
>> | words, junk.
>>
>> and in the shell? LANG LANGUAGE etc?
what happens if you function call replace the default args with
N_(...)
and use _(...) where the vars are used?
Or remove the _(..) from the default args completely?
--
Lgb
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake thusly: > what happens if you function call replace the default args with > N_(...) ? > and use _(...) where the vars are used? I did that... the new strings appear in the output. > Or remove the _(..) from the default args completely? Must experiment. > -- > Lgb - Martin pgp0.pgp Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake
> thusly:
>
>> what happens if you function call replace the default args with
>> N_(...)
>
> ?
N_(...) is just an empty macro (does nothing --- see src/gettext.h)
that enables the po files to document translatable static strings.
See po/Makefile.in.in. The actual call to the gettext translation is
through function _(...)
Example:
char const * const translated_string =
N_("No code to execute. Use N_(...) to flag "
"this message for translation");
void foo() {
string const msg1 = _("Call the gettext translation service");
string const msg2 = _(translated_string);
}
--
Angus
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 11:28:36AM +0100, Angus Leeming spake thusly:
> Martin Vermeer wrote:
>
> > On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake
> > thusly:
> >
> >> what happens if you function call replace the default args with
> >> N_(...)
> >
> > ?
>
> N_(...) is just an empty macro (does nothing --- see src/gettext.h)
> that enables the po files to document translatable static strings.
> See po/Makefile.in.in. The actual call to the gettext translation is
> through function _(...)
>
> Example:
>
> char const * const translated_string =
> N_("No code to execute. Use N_(...) to flag "
>"this message for translation");
>
> void foo() {
> string const msg1 = _("Call the gettext translation service");
> string const msg2 = _(translated_string);
> }
>
>
> --
> Angus
Like this?
Index: xformsBC.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/xformsBC.C,v
retrieving revision 1.19
diff -u -p -r1.19 xformsBC.C
--- xformsBC.C 23 Aug 2003 00:16:47 - 1.19
+++ xformsBC.C 17 Sep 2003 12:51:39 -
@@ -20,7 +20,7 @@
xformsBC::xformsBC(ButtonController const & parent,
string const & cancel, string const & close)
- : GuiBC(parent, cancel, close)
+ : GuiBC(parent, _(cancel), _(close))
{}
Index: xformsBC.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/xformsBC.h,v
retrieving revision 1.17
diff -u -p -r1.17 xformsBC.h
--- xformsBC.h 23 Aug 2003 00:16:47 - 1.17
+++ xformsBC.h 17 Sep 2003 12:51:39 -
@@ -23,7 +23,7 @@ class xformsBC : public GuiBC
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes spake thusly: ... > Or remove the _(..) from the default args completely? > > -- > Lgb Yes, then the error goes away. But do we want that? We want "Cancel" and "Close" translated, don't we? - Martin pgp0.pgp Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> On Wed, Sep 17, 2003 at 11:28:36AM +0100, Angus Leeming spake
thusly:
>
>> Martin Vermeer wrote:
>>
>> > On Wed, Sep 17, 2003 at 10:52:48AM +0200, Lars Gullik Bjønnes
spake
>> > thusly:
>> >
>> >> what happens if you function call replace the default args with
>> >> N_(...)
>> >
>> > ?
>>
>> N_(...) is just an empty macro (does nothing --- see src/gettext.h)
>> that enables the po files to document translatable static strings.
>> See po/Makefile.in.in. The actual call to the gettext translation
is
>> through function _(...)
>>
>> Example:
>>
>> char const * const translated_string =
>> N_("No code to execute. Use N_(...) to flag "
>>"this message for translation");
>>
>> void foo() {
>> string const msg1 = _("Call the gettext translation
service");
>> string const msg2 = _(translated_string);
>> }
>>
>>
>> --
>> Angus
>
> Like this?
No, because this is code executed when the xformsBC constructor is
invoked.
xformsBC(ButtonController const &,
-string const & = _("Cancel"), string const & = _("Close"));
+string const & = N_("Cancel"), string const & = N_("Close"));
ie
void foo() {
ButtonController const & bc = ...;
xformsBC xbc(bc);
}
will result in calls to the 'string const _(string const &);'
function, passing args "Cancel" and "Close".
To continue. This results in output to screen of 'hello'
string str = _("hello");
void foo() {
std::cout << str << std::endl;
}
For reasons I don't follow, _(...) does not work on static strings.
This will also output 'hello'
string str = "hello";
void foo() {
std::cout << _(str) << std::endl;
}
The scripts that extract the string for translation in the po
database won't find the contents of str.
This, however, will print out 'bonjour' if LANG=fr_FR and a .gmo
file existed
string str = N_("hello");
void foo() {
std::cout << _(str) << std::endl;
}
D'ya follow?
N_(...) is simply an identifier used to extract the translatable
strings by the po scripts. Someone comes along and fills in the
translation. Thereater _("hello") will result in the gettext
machinary finding the translation for "hello" and returning that as
the output from _(...).
Angus
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 02:15:35PM +0100, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
...
> >
> > Like this?
>
> No, because this is code executed when the xformsBC constructor is
> invoked.
> xformsBC(ButtonController const &,
> -string const & = _("Cancel"), string const & = _("Close"));
> +string const & = N_("Cancel"), string const & = N_("Close"));
>
> ie
> void foo() {
> ButtonController const & bc = ...;
> xformsBC xbc(bc);
> }
> will result in calls to the 'string const _(string const &);'
> function, passing args "Cancel" and "Close".
>
> To continue. This results in output to screen of 'hello'
>
> string str = _("hello");
> void foo() {
> std::cout << str << std::endl;
> }
>
> For reasons I don't follow, _(...) does not work on static strings.
>
>
> This will also output 'hello'
>
> string str = "hello";
> void foo() {
> std::cout << _(str) << std::endl;
> }
>
> The scripts that extract the string for translation in the po
> database won't find the contents of str.
>
> This, however, will print out 'bonjour' if LANG=fr_FR and a .gmo
> file existed
> string str = N_("hello");
> void foo() {
> std::cout << _(str) << std::endl;
> }
>
> D'ya follow?
> N_(...) is simply an identifier used to extract the translatable
> strings by the po scripts. Someone comes along and fills in the
> translation. Thereater _("hello") will result in the gettext
> machinary finding the translation for "hello" and returning that as
> the output from _(...).
>
>
> Angus
Yes, I know how gettext works -- I did the first Dutch and Finnish
translations remember? But I still don't get what Lars wanted
me to do. Please bend it in copperwire for me. Remember I'm a little
dumb :-)
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> Yes, I know how gettext works -- I did the first Dutch and Finnish
> translations remember? But I still don't get what Lars wanted
> me to do. Please bend it in copperwire for me. Remember I'm a little
> dumb :-)
My misunderstanding.
Ok, I think that Lars is suggesting
// file frontends/xforms/xformsBC.h
class xformsBC : public GuiBC {
public:
xformsBC(ButtonController const &,
string const & = N_("Cancel"),
string const & = N_("Close"));
...
];
// file frontends/controllers/BCView.tmpl
template
void GuiBC::refresh() const
{
...
bp().buttonStatus(ButtonPolicy::CANCEL);
if (enabled)
setButtonLabel(cancel_, _(cancel_label_));
else
setButtonLabel(cancel_, _(close_label_));
}
}
or presumably alternatively:
// file frontends/xforms/xformsBC.h
void xformsBC::setButtonLabel(FL_OBJECT * obj, string const & label)
const
{
fl_set_object_label(obj, _(label).c_str());
}
--
Angus
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 02:53:27PM +0100, Angus Leeming spake thusly:
> Martin Vermeer wrote:
> > Yes, I know how gettext works -- I did the first Dutch and Finnish
> > translations remember? But I still don't get what Lars wanted
> > me to do. Please bend it in copperwire for me. Remember I'm a little
> > dumb :-)
>
> My misunderstanding.
>
> Ok, I think that Lars is suggesting
>
> // file frontends/xforms/xformsBC.h
> class xformsBC : public GuiBC {
> public:
> xformsBC(ButtonController const &,
> string const & = N_("Cancel"),
> string const & = N_("Close"));
> ...
> ];
...
> or presumably alternatively:
>
> // file frontends/xforms/xformsBC.C
> void xformsBC::setButtonLabel(FL_OBJECT * obj, string const & label)
> const
> {
> fl_set_object_label(obj, _(label).c_str());
> }
Yes! This bites. At least for Cancel and Close.
Now the same for the inset dialog headers (Note, Minipage, ...) I know
where to put the N_(), but where goes _()?
- Martin
> --
> Angus
>
By the way, I run CVS LyX uninstalled. Relevant?
- M
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
>> or presumably alternatively:
>>
>> // file frontends/xforms/xformsBC.C
>> void xformsBC::setButtonLabel(FL_OBJECT * obj, string const &
>> label) const
>> {
>> fl_set_object_label(obj, _(label).c_str());
>> }
>
> Yes! This bites. At least for Cancel and Close.
>
> Now the same for the inset dialog headers (Note, Minipage, ...) I
> know where to put the N_(), but where goes _()?
Somewhere in the path of code executed at run time.
Try FormDialogView.C
FormDialogView::FormDialogView(Dialog & parent,
string const & t, bool allowResize)
-: Dialog::View(parent, t),
+: Dialog::View(parent, _(t)),
warning_posted_(false), message_widget_(0),
minw_(0), minh_(0), allow_resize_(allowResize),
icon_pixmap_(0), icon_mask_(0),
tooltips_(new Tooltips())
{}
or alternatively:
void FormDialogView::prepare_to_show()
{
...
if (!lyxrc.dialogs_iconify_with_main)
- fl_winicontitle(form()->window, getTitle().c_str());
+ fl_winicontitle(form()->window, _(getTitle()).c_str());
...
}
void FormDialogView::show()
{
...
- string const maximize_title = "LyX: " + getTitle();
+ string const maximize_title = "LyX: " + _(getTitle());
> By the way, I run CVS LyX uninstalled. Relevant?
Not to the fact that the code is crashing, no.
Incidentally, maybe a script would help automate the changing of
those _("Minipage settings") to N_(...)
for file in Form*.C; do
sed 's/\(^[ ]*: base_class([^_]*\)_/\1N_/' $file > tmp
cmp -s $file tmp && continue
diff -u $file tmp
mv -i tmp $file
done
--
Angus
Re: Core dump on exit after pasting inset in inset
Angus Leeming wrote:
> Incidentally, maybe a script would help automate the changing of
> those _("Minipage settings") to N_(...)
>
> for file in Form*.C; do
> sed 's/\(^[ ]*: base_class([^_]*\)_/\1N_/' $file > tmp
> cmp -s $file tmp && continue
> diff -u $file tmp
> mv -i tmp $file
> done
Hmmm. Dunno about your mail reader, but mine has mangled that
'^[ ]*: base'
part. The square bracket should contain a single space and a single
tab. If you're typing this from the command line, the tab is
Cntl-vCntl-i
--
Angus
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 04:32:50PM +0100, Angus Leeming spake thusly:
...
> or alternatively:
> void FormDialogView::prepare_to_show()
> {
> ...
> if (!lyxrc.dialogs_iconify_with_main)
> - fl_winicontitle(form()->window, getTitle().c_str());
> + fl_winicontitle(form()->window, _(getTitle()).c_str());
> ...
> }
>
> void FormDialogView::show()
> {
> ...
> - string const maximize_title = "LyX: " + getTitle();
> + string const maximize_title = "LyX: " + _(getTitle());
Yes! This does the trick.
Shall I prepare a patch?
> > By the way, I run CVS LyX uninstalled. Relevant?
>
> Not to the fact that the code is crashing, no.
What I don't like though is that localization doesn't work this
way so I cannot test it.
> Incidentally, maybe a script would help automate the changing of
> those _("Minipage settings") to N_(...)
Yeah... we should catch them all.
> --
> Angus
>
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> Yes! This does the trick.
Great! I wonder what changed between 13x and 14x in this regard.
> Shall I prepare a patch?
Why not.
>> > By the way, I run CVS LyX uninstalled. Relevant?
>> Not to the fact that the code is crashing, no.
> What I don't like though is that localization doesn't work this
> way so I cannot test it.
Install locally. Something like this should do the trick. Note that
the important line is the penultimate one. See main.C and thereafter
the code in ${LYX_TOP_DIR}/intl
$ INSTALL_DIR=/home/martin/lyx/test-install
$ configure --prefix=${INSTALL_DIR}
$ make
$ make install
$ PATH=$PATH:${INSTALL_DIR}/bin
$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${INSTALL_DIR}/lib
$ LYX_LOCALEDIR=$LYX_LOCALEDIR:${INSTALL_DIR}/share/lyx
$ export PATH LD_LIBRARY_PATH LYX_LOCALEDIR
--
Angus
Re: Core dump on exit after pasting inset in inset
Looking deeper, LOCALEDIR should be ${INSTALL_DIR}/share/locale I
think
Angus
| Install locally. Something like this should do the trick.
| Note that the important line is the penultimate one.
| See main.C and thereafter the code in ${LYX_TOP_DIR}/intl
| $ INSTALL_DIR=/home/martin/lyx/test-install
| $ configure --prefix=${INSTALL_DIR}
| $ make
| $ make install
| $ PATH=$PATH:${INSTALL_DIR}/bin
| $ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${INSTALL_DIR}/lib
| $ LYX_LOCALEDIR=$LYX_LOCALEDIR:${INSTALL_DIR}/share/lyx
| $ export PATH LD_LIBRARY_PATH LYX_LOCALEDIR
Re: Core dump on exit after pasting inset in inset
On Wed, Sep 17, 2003 at 06:35:10PM +0100, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
> > Yes! This does the trick.
>
> Great! I wonder what changed between 13x and 14x in this regard.
>
> > Shall I prepare a patch?
>
> Why not.
Here's the patch.
Notes:
1) To suppress the bug, it would be sufficient to change _( to N_(
only in those dialogs that can be opened from clicking on insets. I
applied the change to all dialogs however. I don't think it hurts.
2) I still have the feeling that this only prevents a deeper bug from
expressing itself. Remember that the crash only happened if an inset
was copied and pasted; creating the same on-screen geometry by
creating the 'guilty' inset from the menu did *not* lead to a crash.
There is something in cut&paste of insets that's wrong.
3) I discovered a new (?) bug:
a) create an inset, e.g., note;
b) insert a math inset into it;
c) copy and paste the math inset to inside the note inset;
d) exit without saving.
I added instrumentation to Dialogs::find showing that the name argument
is corrupted/undefined. The name is very long and will give a crash
elsewhere. Again this bug will not manifest itself if the second
mathinset is created the regular way. There is something fishy with
cut&paste...
I suggest to put this patch in and take it from there.
- Martin
Index: Dialogs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/Dialogs.C,v
retrieving revision 1.28
diff -u -p -r1.28 Dialogs.C
--- Dialogs.C 5 Sep 2003 10:55:42 - 1.28
+++ Dialogs.C 18 Sep 2003 07:17:53 -
@@ -18,6 +18,7 @@
#include
#include
+#include "debug.h"
// Note that static boost signals break some compilers, so this wrapper
@@ -77,6 +78,10 @@ Dialogs::Dialogs(LyXView & lyxview)
Dialog * Dialogs::find(string const & name)
{
+ if (name.size() > 100) {
+ lyxerr << "Name problem Dialogs::find, length " << name.size() << endl;
+ return 0;
+ }
if (!isValidName(name))
return 0;
Index: xforms/FormAboutlyx.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormAboutlyx.C,v
retrieving revision 1.28
diff -u -p -r1.28 FormAboutlyx.C
--- xforms/FormAboutlyx.C 5 Sep 2003 18:02:18 - 1.28
+++ xforms/FormAboutlyx.C 18 Sep 2003 07:17:54 -
@@ -40,7 +40,7 @@ bool const scalableTabfolders = true;
typedef FormController > base_class;
FormAboutlyx::FormAboutlyx(Dialog & parent)
- : base_class(parent, _("About LyX"), scalableTabfolders)
+ : base_class(parent, N_("About LyX"), scalableTabfolders)
{}
Index: xforms/FormBibitem.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormBibitem.C,v
retrieving revision 1.31
diff -u -p -r1.31 FormBibitem.C
--- xforms/FormBibitem.C9 Sep 2003 22:13:40 - 1.31
+++ xforms/FormBibitem.C18 Sep 2003 07:17:54 -
@@ -28,7 +28,7 @@ using lyx::support::compare;
typedef FormController > base_class;
FormBibitem::FormBibitem(Dialog & parent)
- : base_class(parent, _("Bibliography Entry"))
+ : base_class(parent, N_("Bibliography Entry"))
{}
Index: xforms/FormBibtex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormBibtex.C,v
retrieving revision 1.61
diff -u -p -r1.61 FormBibtex.C
--- xforms/FormBibtex.C 9 Sep 2003 22:13:40 - 1.61
+++ xforms/FormBibtex.C 18 Sep 2003 07:17:54 -
@@ -42,7 +42,7 @@ using std::vector;
typedef FormController > base_class;
FormBibtex::FormBibtex(Dialog & parent)
- : base_class(parent, _("BibTeX Database"))
+ : base_class(parent, N_("BibTeX Database"))
{}
Index: xforms/FormBranch.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormBranch.C,v
retrieving revision 1.4
diff -u -p -r1.4 FormBranch.C
--- xforms/FormBranch.C 9 Sep 2003 18:27:22 - 1.4
+++ xforms/FormBranch.C 18 Sep 2003 07:17:54 -
@@ -25,7 +25,7 @@
typedef FormController > base_class;
FormBranch::FormBranch(Dialog & parent)
- : base_class(parent, _("Branch"))
+ : base_class(parent, N_("Branch"))
{}
Index: xforms/FormChanges.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormChanges.C,v
retrieving revision 1.9
diff -u -p -r1.9 FormChanges.C
--- xforms/FormChanges.C5 Sep 2003 13:15:42 - 1.9
+++ xforms/FormChanges.C18 Sep 2003 07:17:54 -
@@ -23,7 +23,7 @@
typedef FormController > base_class;
FormChanges::FormChanges(Dialog & parent)
- : base_class(parent, _("Merge Changes"))
+ : base_class(parent, N_("Merg
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote: > 3) I discovered a new (?) bug: > > a) create an inset, e.g., note; > b) insert a math inset into it; > c) copy and paste the math inset to inside the note inset; > d) exit without saving. I don't see it. Alfredo
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote:
> Here's the patch.
And I understand how it is triggered. We have a sort of 'race'
condition between the destruction of two static variables.
In gettext.C:
Messages & getLyXMessages() {
static Messages lyx_messages;
return lyx_messages;
}
In Dialogs.C
namespace {
BugfixSignal >
hideSignal;
}
It just so happens that on my box, hideSignal is destroyed before
lyx_messages. On your box the converse is true.
(Note for Lars: the Dialogs hide member function is a static function.
It is invoked when the inset is destroyed and should hide the inset's
dialog in all LyXViews. So this is correct IMO.)
So, what triggers the bug/crash. The (stupid) creation of dialogs
unnecessarily when LyXView::getDialogs() is invoked to hide() or
update() dialogs that are not visible and indeed haven't ever been
visible because they haven't been created.
So, IMO, the proper fix is not to build the dialogs in such cases.
Your patch is essentially a work around to fix this breakage. It does
fix the immediate problem because the Dialogs::find member function
will cause the named dialog to be created (calls its constructor) but
does not go on to call one of the other FormXYZ member functions
where your patch re-positions the _(...) call.
So, now that we understand what is happening, I think we should ditch
your patch and apply mine. Yours is a work around broken behaviour.
Mine cures the source of the breakage.
Thoughts?
Angus
--
AngusIndex: src/frontends/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/ChangeLog,v
retrieving revision 1.225
diff -u -p -r1.225 ChangeLog
--- src/frontends/ChangeLog 15 Sep 2003 15:20:16 - 1.225
+++ src/frontends/ChangeLog 15 Sep 2003 20:47:46 -
@@ -1,5 +1,12 @@
2003-09-15 Angus Leeming <[EMAIL PROTECTED]>
+ * Dialogs.[Ch] (find): renamed as find_or_build.
+ (update, hideSlot): don't call find_or_build to find the requested dialog.
+ Instead, search dialogs_, the list of already constructed dialogs. If it
+ ain't found, do nothing.
+
+2003-09-15 Angus Leeming <[EMAIL PROTECTED]>
+
* Painter.C: add #include "LColor.h".
(rectText): pass EnumLColor args, rather than LColor::color ones.
Index: src/frontends/Dialogs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/Dialogs.C,v
retrieving revision 1.28
diff -u -p -r1.28 Dialogs.C
--- src/frontends/Dialogs.C 5 Sep 2003 10:55:42 - 1.28
+++ src/frontends/Dialogs.C 15 Sep 2003 20:47:46 -
@@ -75,7 +75,7 @@ Dialogs::Dialogs(LyXView & lyxview)
}
-Dialog * Dialogs::find(string const & name)
+Dialog * Dialogs::find_or_build(string const & name)
{
if (!isValidName(name))
return 0;
@@ -83,18 +83,17 @@ Dialog * Dialogs::find(string const & na
std::map::iterator it =
dialogs_.find(name);
- if (it == dialogs_.end()) {
- dialogs_[name] = DialogPtr(build(name));
- return dialogs_[name].get();
- }
+ if (it != dialogs_.end())
+ return it->second.get();
- return it->second.get();
+ dialogs_[name] = DialogPtr(build(name));
+ return dialogs_[name].get();
}
void Dialogs::show(string const & name, string const & data)
{
- Dialog * dialog = find(name);
+ Dialog * dialog = find_or_build(name);
if (!dialog)
return;
@@ -105,7 +104,7 @@ void Dialogs::show(string const & name,
void Dialogs::show(string const & name, string const & data, InsetBase * inset)
{
- Dialog * dialog = find(name);
+ Dialog * dialog = find_or_build(name);
if (!dialog)
return;
@@ -127,10 +126,12 @@ bool Dialogs::visible(string const & nam
void Dialogs::update(string const & name, string const & data)
{
- Dialog * dialog = find(name);
- if (!dialog)
+ std::map::const_iterator it =
+ dialogs_.find(name);
+ if (it == dialogs_.end())
return;
+ Dialog * const dialog = it->second.get();
if (dialog->isVisible())
dialog->update(data);
}
@@ -138,13 +139,15 @@ void Dialogs::update(string const & name
void Dialogs::hideSlot(string const & name, InsetBase * inset)
{
- Dialog * dialog = find(name);
- if (!dialog)
+ std::map::const_iterator it =
+ dialogs_.find(name);
+ if (it == dialogs_.end())
return;
if (inset && inset != getOpenInset(name))
return;
+ Dialog * const dialog = it->second.get();
if (dialog->isVisible())
dialog->hide();
open_insets_[name] = 0;
Index: src/frontends/Dialogs.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/Dialogs.h,v
retrieving revision 1.90
diff -u -p -r1.90 Dialogs.h
--- src/frontends/Dialogs.h 7 Sep 2003 21:25:33 - 1.90
+++ src/frontends/Dialogs.h 15 Sep 2003 20:47:46 -
@@ -132,7 +132,7 @@ private:
///
bool isValidName(string const & name) const;
///
- Dialog * find(string const & name);
+ Dialog * find_or_build(string const & name);
///
Dialog * build(string c
Re: Core dump on exit after pasting inset in inset
Alfredo Braunstein wrote: > Martin Vermeer wrote: > >> 3) I discovered a new (?) bug: >> >> a) create an inset, e.g., note; >> b) insert a math inset into it; >> c) copy and paste the math inset to inside the note inset; >> d) exit without saving. > > I don't see it. No, it's going to be a compiler-specific lottery because it is ultimately caused by this 'race' between the order of destruction of two static variables. Let's just prevent the race from starting in the first place. -- Angus
Re: Core dump on exit after pasting inset in inset
On Thu, Sep 18, 2003 at 09:25:41AM +, Angus Leeming wrote: > Alfredo Braunstein wrote: > > > Martin Vermeer wrote: > > > >> 3) I discovered a new (?) bug: > >> > >> a) create an inset, e.g., note; > >> b) insert a math inset into it; > >> c) copy and paste the math inset to inside the note inset; > >> d) exit without saving. > > > > I don't see it. > > No, it's going to be a compiler-specific lottery because it is > ultimately caused by this 'race' between the order of destruction of > two static variables. Let's just prevent the race from starting in > the first place. As the destruction order is the reversed construction order you could specify a certain order if you need to. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: Core dump on exit after pasting inset in inset
Andre Poenitz wrote: > As the destruction order is the reversed construction order you > could specify a certain order if you need to. Let's just not go there in the first place. -- Angus
Re: Core dump on exit after pasting inset in inset
On Thu, Sep 18, 2003 at 09:45:06AM +, Angus Leeming wrote: > Andre Poenitz wrote: > > As the destruction order is the reversed construction order you > > could specify a certain order if you need to. > > Let's just not go there in the first place. Fine with me. Andre'
Re: Core dump on exit after pasting inset in inset
On Thu, Sep 18, 2003 at 09:05:57AM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
> > Here's the patch.
>
> And I understand how it is triggered. We have a sort of 'race'
> condition between the destruction of two static variables.
>
> In gettext.C:
> Messages & getLyXMessages() {
> static Messages lyx_messages;
> return lyx_messages;
> }
>
> In Dialogs.C
> namespace {
> BugfixSignal >
> hideSignal;
> }
>
> It just so happens that on my box, hideSignal is destroyed before
> lyx_messages. On your box the converse is true.
>
> (Note for Lars: the Dialogs hide member function is a static function.
> It is invoked when the inset is destroyed and should hide the inset's
> dialog in all LyXViews. So this is correct IMO.)
>
> So, what triggers the bug/crash. The (stupid) creation of dialogs
> unnecessarily when LyXView::getDialogs() is invoked to hide() or
> update() dialogs that are not visible and indeed haven't ever been
> visible because they haven't been created.
>
> So, IMO, the proper fix is not to build the dialogs in such cases.
Great! I was myself wondering about that. What's the sense in creating
a dialog that doesn't even exist, just so that you can get rid of it?
> Your patch is essentially a work around to fix this breakage. It does
> fix the immediate problem because the Dialogs::find member function
> will cause the named dialog to be created (calls its constructor) but
> does not go on to call one of the other FormXYZ member functions
> where your patch re-positions the _(...) call.
>
> So, now that we understand what is happening, I think we should ditch
> your patch and apply mine. Yours is a work around broken behaviour.
> Mine cures the source of the breakage.
I very much agree -- provided it works. (Do you mean the dialogs.diff
patch you posted here much earlier? But you called that yourself
'curing by hiding', not a fix. What should I believe?)
> Thoughts?
> Angus
>
>
> --
> Angus
- Martin
pgp0.pgp
Description: PGP signature
Re: Core dump on exit after pasting inset in inset
On Thursday 18 September 2003 11:58 am, Martin Vermeer wrote: > > your patch and apply mine. Yours is a work around broken behaviour. > > Mine cures the source of the breakage. > > I very much agree -- provided it works. (Do you mean the dialogs.diff > patch you posted here much earlier? But you called that yourself > 'curing by hiding', not a fix. What should I believe?) I did, but only because I did not understand the problem. I think I've explained why the bug was triggered, why I'm treating its cause and why you are treating the synptoms. Without your detective work, however, we wouldn't understand what the symptoms mean and whether the proposed cure will be successful. Now we do. Convinced yet? Angus ps, see if you can trigger the bug with current cvs. Also the math one...
Re: Core dump on exit after pasting inset in inset
On Thu, Sep 18, 2003 at 12:57:40PM +, Angus Leeming spake thusly: > On Thursday 18 September 2003 11:58 am, Martin Vermeer wrote: > > > your patch and apply mine. Yours is a work around broken behaviour. > > > Mine cures the source of the breakage. > > > > I very much agree -- provided it works. (Do you mean the dialogs.diff > > patch you posted here much earlier? But you called that yourself > > 'curing by hiding', not a fix. What should I believe?) > > I did, but only because I did not understand the problem. > > I think I've explained why the bug was triggered, why I'm treating its cause > and why you are treating the synptoms. > > Without your detective work, however, we wouldn't understand what the symptoms > mean and whether the proposed cure will be successful. Now we do. > > Convinced yet? > Angus > > ps, see if you can trigger the bug with current cvs. Also the math one... Yes, the bug is gone. So is the math bug. These kind of bugs based upon unspecified compiler behaviour are hell to hunt down. I think we did our good deed for this week! However #1366 is still there. Any chance it may have a similar background? - Martin pgp0.pgp Description: PGP signature
Re: Core dump on exit after pasting inset in inset
Martin Vermeer wrote: >> ps, see if you can trigger the bug with current cvs. Also the math one... > > Yes, the bug is gone. So is the math bug. Good news indeed. > These kind of bugs based upon unspecified compiler behaviour are hell > to hunt down. I think we did our good deed for this week! > > However #1366 is still there. Any chance it may have a similar > background? Shrug. Dunno. Looking at the backtrace though, I suspect that there are more likely candidates out there... -- Angus
RE: core dump select in middle of text in table
On 04-Jan-2001 [EMAIL PROTECTED] wrote: > > I get core dump when I select and > drag in middle of text with left button in a table with text. I cannot reproduce this! How do you make it crash? > Text in tables can't be selected with doubleclick. > This is a missing feature, that most probably will be added in 1.2.0. Greets, Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Does the name Pavlov ring a bell?
Re: core dump bug (should be a simple fix) in lyx1.1.5cvs
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan> This is in the latest CVS. Start lyx as "lyx filename.lyx" and Kayvan> it crashes. No, it just exits cleanly :) Andre, it seems something is wrong at the end of easyParse. What was the intent of the 'gui=false' at the end? JMarc
Re: core dump bug (should be a simple fix) in lyx1.1.5cvs
On Tue, Mar 21, 2000 at 05:39:25PM +0100, Jean-Marc Lasgouttes wrote:
> > "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes:
>
> Kayvan> This is in the latest CVS. Start lyx as "lyx filename.lyx" and
> Kayvan> it crashes.
>
> No, it just exits cleanly :) Andre, it seems something is wrong at the
> end of easyParse. What was the intent of the 'gui=false' at the end?
In fact, just removing that line seems to fix the problem. It seems to be
misplaced.
Here's the "fix" --- though I suspect there are other crashing bugs here
in the argument handling code.
---Kayvan
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
? lyx-1.1.5cvs.tar.gz
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v
retrieving revision 1.252
diff -u -r1.252 ChangeLog
--- ChangeLog 2000/03/20 18:55:57 1.252
+++ ChangeLog 2000/03/21 22:42:07
@@ -1,3 +1,9 @@
+2000-03-21 Kayvan A. Sylvan <[EMAIL PROTECTED]>
+
+ * src/lyx_main.C (easyParse): Removed misplaced gui=false which
+ caused lyx to startup with no GUI in place, causing in a crash
+ upon startup when called with arguments.
+
2000-03-20 José Abílio Matos <[EMAIL PROTECTED]>
* src/lyxrc.[Ch] Removed \sgml_extra_options, added 6 other flags
Index: src/lyx_main.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_main.C,v
retrieving revision 1.24
diff -u -r1.24 lyx_main.C
--- src/lyx_main.C 2000/03/20 16:37:49 1.24
+++ src/lyx_main.C 2000/03/21 22:42:16
@@ -575,7 +575,6 @@
"ps...] after ")
<< arg << _(" switch!") << endl;
}
- gui = false;
}
return gui;
}
Re: core dump bug (should be a simple fix) in lyx1.1.5cvs
> No, it just exits cleanly :) Andre, it seems something is wrong at the > end of easyParse. What was the intent of the 'gui=false' at the end? Urm... I don't have the sources here but I think it was intented to suppress gui initialization. This is, of course, only sensible once all the no-gui stuff is in. And the flag was in there already, it's not my invention. Well, while I am thinking about it... it should be set to 'false' only if --export was requested. Did I set it to false in this case only? I am not sure. Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: core dump bug (should be a simple fix) in lyx1.1.5cvs
On Thu, Mar 23, 2000 at 08:28:47AM +0100, Andre Poenitz wrote: > > No, it just exits cleanly :) Andre, it seems something is wrong at the > > end of easyParse. What was the intent of the 'gui=false' at the end? > > Urm... I don't have the sources here but I think it was intented to > suppress gui initialization. This is, of course, only sensible once > all the no-gui stuff is in. And the flag was in there already, it's not > my invention. > > Well, while I am thinking about it... it should be set to 'false' only > if --export was requested. Did I set it to false in this case only? I > am not sure. You also set it to false if "-nw" is specified. This also results in a core dump. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: core dump bug (should be a simple fix) in lyx1.1.5cvs
> > if --export was requested. Did I set it to false in this case only? I > > am not sure. > > You also set it to false if "-nw" is specified. This also results in a core > dump. The (very old) -nw switch was intended to start LyX without gui. This never has been possible, so the switch was ignored (which is broken behaviour as well). The best current solution probably is to set nogui to false in any case until all of the nogui stuff is in and working. And that means we have to find the LyXText bug first if I understand Lars correctly :-) Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
