On Wed, 10 Mar 1999, Jean-Marc Lasgouttes wrote:
> >>>>> "Volker" == Volker Enderlein <[EMAIL PROTECTED]> writes:
>
> Volker> Hi, I've got some problems while running LyX 1.0.0 (02/23/99)
> Volker> and 1.0.1 (03/04/99) on my SGI-Workstation (SGI Indigo2 IMPACT
> Volker> 10000, IRIX64 wega 6.2 06101031 IP28). During the Compilation
Did you have previous versions of LyX working at all or are you new to
LyX? Just wondering if we can narrow down the problem a bit better.
> Volker> with the native CC and cc compilers (switches -32) no errors
> Volker> occur. But after starting LyX it crashes with a SIGSEGV
> Volker> message without opening any window. I'm using the xforms
> Volker> library version 0.88 and the xpm library version 4.7.
(after some thought I came back and wrote this)
Could you try running lyx with a private colormap.
lyx -private
I get crashes caused by xforms when there aren't enough colours available
and I'm wondering if we are seeing something similar happening here.
> Volker> I've also tried the g++ and gcc compilers but with the same
> Volker> result. gcc-2.7.2, mips-sgi-irix5.2 - binary compatible in 32
> Volker> bit mode to irix646.2 (my admin said to me)
>
> Volker> (gdb) run Starting program:
> Volker> /home/ifm/volker/temp/lyx-1.0.0/src/lyx1.0.0sgi
>
> Volker> Program received signal SIGSEGV, Segmentation fault. 0x54dfe0
> Volker> in LString::operator= () (gdb) bt #0 0x54dfe0 in
> Volker> LString::operator= () #1 0x446d54 in LyXGUI::LyXGUI () #2
> Volker> 0x43f248 in LyX::LyX () #3 0x43effc in main () #4 0x43ee38 in
> Volker> __start () at crt1text.s:165 (gdb) quit
>
> What is the linke that your gcc uses? I think it might be a resurgence
> of the infamous static initialization order for the LString
> class. Could you provide us with a backtrace with debug information?
The line in question is probably:
background_color = b_c; // lyx_gui.C:191
Both background_color (an LString) and b_c (a char[32]) are declared
earlier at file scope (lines 123 and 124 respectively).
b_c is set by xforms in the fl_get_app_resources() call (line 181).
There should be no "static initialisation order" problems within LString
because the static empty_reps are all local to the functions that use them
(and none of those are inlined which is what caused some difficulties in
the past; unless of course all those compilers for mips are so stupid they
can't handle local statics correctly and I doubt that's the case).
Likewise, background_color and b_c are at file scope and according to the
C++ standard they are initialised before any of the functions or methods
implemented in the file are used.
If background_color hasn't been constructed yet then we could certainly
see this kind of crash although it would probably occur in the inlined
lose() call from within operator=(char const *). Which wouldn't be seen
on the stack trace unless debugging info was available.
Another possibility is the strlen() in operator=(char const *) but again
that should have shown up on the trace. Likewise the memcpy() call.
The only other possibility I can think of is if somehow we've managed to
attempt to delete LString::LString()::empty_rep within lose(). But this
should be impossible.
Stumped,
Allan. (ARRae)
