R == R Lahaye [EMAIL PROTECTED] writes:
R Jean-Marc Lasgouttes wrote:
R == R Lahaye [EMAIL PROTECTED] writes:
R For some reason the C compiler flags always are -O2, irrespective
R of the value given to the configure script; is that correct?
It is not really correct, but we've been lazy
> "R" == R Lahaye <[EMAIL PROTECTED]> writes:
R> Jean-Marc Lasgouttes wrote:
>> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
>>
R> For some reason the C compiler flags always are -O2, irrespective
R> of the value given to the configure script; is that correct?
>> It is not really
R. Lahaye [EMAIL PROTECTED] writes:
| Andre Poenitz wrote:
On Mon, Jul 01, 2002 at 12:02:51PM +0900, R. Lahaye wrote:
It's the recursion call in math_support.C::searchFont at line 596.
Ah... this probably means it does not find the proper point
for mathnormal and due to my stupid way to
On Tue, Jul 02, 2002 at 03:09:52PM +0900, R. Lahaye wrote:
fontinfo * searchFont(string const name)
{
int const n = sizeof(fontinfos) / sizeof(fontinfo);
char dummy[9]; // dummy declaration, without being used !?!?
for (int i = 0; i n; ++i)
if
On Tue, Jul 02, 2002 at 09:35:47AM +0200, Lars Gullik Bjønnes wrote:
And why have this function recurse anyway?
Just because I did not want to hardcode the position of mathnormal (the
safe fall back). I have that now (and moved mathnormal to position 0).
Actually, I think we could even assert()
Andre Poenitz wrote:
On Tue, Jul 02, 2002 at 03:09:52PM +0900, R. Lahaye wrote:
Somehow, this may force a correct stack management, or something.
Could you initialize the dummy array with some special value and dump the
contents before you leave the function?
Somebody is writing in
On Tue, Jul 02, 2002 at 11:00:15PM +0900, R. Lahaye wrote:
Hm. This could then be some optimization bug like re-using stackframes when
it really should not.
Could you try to remove any optimization (configure with -O0 or so)
and/or look at the produced assembler code?
Bingo! with -O0
R == R Lahaye [EMAIL PROTECTED] writes:
R For some reason the C compiler flags always are -O2, irrespective
R of the value given to the configure script; is that correct?
It is not really correct, but we've been lazy :) Anyway there is not a
lot of C code to compile...
JMarc
Jean-Marc Lasgouttes wrote:
R == R Lahaye [EMAIL PROTECTED] writes:
R For some reason the C compiler flags always are -O2, irrespective
R of the value given to the configure script; is that correct?
It is not really correct, but we've been lazy :) Anyway there is not a
lot of C code
"R. Lahaye" <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>>
>> On Mon, Jul 01, 2002 at 12:02:51PM +0900, R. Lahaye wrote:
>> > It's the recursion call in math_support.C::searchFont at line 596.
>>
>> Ah... this probably means it does not find the proper point
>> for mathnormal and due to
On Tue, Jul 02, 2002 at 03:09:52PM +0900, R. Lahaye wrote:
> fontinfo * searchFont(string const & name)
> {
> int const n = sizeof(fontinfos) / sizeof(fontinfo);
> char dummy[9]; // dummy declaration, without being used !?!?
>
> for (int i = 0; i < n; ++i)
> if
On Tue, Jul 02, 2002 at 09:35:47AM +0200, Lars Gullik Bjønnes wrote:
> And why have this function recurse anyway?
Just because I did not want to hardcode the position of "mathnormal" (the
safe fall back). I have that now (and moved mathnormal to position 0).
Actually, I think we could even
Andre Poenitz wrote:
>
> On Tue, Jul 02, 2002 at 03:09:52PM +0900, R. Lahaye wrote:
> > Somehow, this may force a correct stack management, or something.
>
> Could you initialize the dummy array with some special value and dump the
> contents before you leave the function?
> Somebody is writing
On Tue, Jul 02, 2002 at 11:00:15PM +0900, R. Lahaye wrote:
> > Hm. This could then be some optimization bug like re-using stackframes when
> > it really should not.
> > Could you try to remove any optimization (configure with -O0 or so)
> > and/or look at the produced assembler code?
>
> Bingo!
> "R" == R Lahaye <[EMAIL PROTECTED]> writes:
R> For some reason the C compiler flags always are -O2, irrespective
R> of the value given to the configure script; is that correct?
It is not really correct, but we've been lazy :) Anyway there is not a
lot of C code to compile...
JMarc
Jean-Marc Lasgouttes wrote:
>
> > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
>
> R> For some reason the C compiler flags always are -O2, irrespective
> R> of the value given to the configure script; is that correct?
>
> It is not really correct, but we've been lazy :) Anyway there is not
On Mon, Jul 01, 2002 at 12:02:51PM +0900, R. Lahaye wrote:
It's the recursion call in math_support.C::searchFont at line 596.
When I replace
return searchFont(mathnormal);
by
return fontinfos[8];
everything's fine; no SIGSEGV crash anymore when opening math mode.
A
Andre Poenitz wrote:
On Mon, Jul 01, 2002 at 12:02:51PM +0900, R. Lahaye wrote:
It's the recursion call in math_support.C::searchFont at line 596.
Ah... this probably means it does not find the proper point
for mathnormal and due to my stupid way to implement this fall
back you run into
On Mon, Jul 01, 2002 at 12:02:51PM +0900, R. Lahaye wrote:
> It's the recursion call in math_support.C::searchFont at line 596.
> When I replace
>
> return searchFont("mathnormal");
>
> by
>
> return [8];
>
> everything's fine; no SIGSEGV crash anymore when opening math mode.
>
>
Andre Poenitz wrote:
>
> On Mon, Jul 01, 2002 at 12:02:51PM +0900, R. Lahaye wrote:
> > It's the recursion call in math_support.C::searchFont at line 596.
>
> Ah... this probably means it does not find the proper point
> for mathnormal and due to my stupid way to implement this fall
> back you
Andre Poenitz wrote:
On Thu, Jun 27, 2002 at 06:40:27PM +0900, R. Lahaye wrote:
Then I get stuck, but when I replace the body of
math_support.C::searchFont() merely by
fontinfo * searchFont(string const name)
{
return fontinfos[8];
}
the problem is solved.
Are
Andre Poenitz wrote:
>
> On Thu, Jun 27, 2002 at 06:40:27PM +0900, R. Lahaye wrote:
> > Then I get stuck, but when I replace the body of
> > math_support.C::searchFont() merely by
> >
> >fontinfo * searchFont(string const & name)
> >{
> > return [8];
> >}
> >
> > the problem is
Andre Poenitz wrote:
There happens nothing special. Only destructors of the automatic variables
are run. As I said, I guess your heap is corrupted already when you come
there, so the problem might be at any point before that time.
Aha, let me give a last shot:
when I replace the body of
On Thu, Jun 27, 2002 at 03:45:25PM +0900, R. Lahaye wrote:
Aha, let me give a last shot:
when I replace the body of readSymbols::math_factory.C by simply return;,
LyX seems to keep running like a charm.
Aparently the use of variables in that particular body of readSymbols
makes the heap,
Andre,
I think I got a bit closer to the culprit!
Step by step I zoomed in on what the SIGSEGV is causing.
In src/mathed/math_factory.C
readSymbols() calls math_font_available(tmp.inset)
math_font_available() calls augmentFont(f, name)
augmentFont() calls searchFont(name)
Then I
On Thu, Jun 27, 2002 at 06:40:27PM +0900, R. Lahaye wrote:
Then I get stuck, but when I replace the body of
math_support.C::searchFont() merely by
fontinfo * searchFont(string const name)
{
return fontinfos[8];
}
the problem is solved.
Are you having any idea what could
Andre Poenitz wrote:
>
> There happens nothing special. Only destructors of the automatic variables
> are run. As I said, I guess your heap is corrupted already when you come
> there, so the problem might be at any point before that time.
Aha, let me give a last shot:
when I replace the body of
On Thu, Jun 27, 2002 at 03:45:25PM +0900, R. Lahaye wrote:
> Aha, let me give a last shot:
> when I replace the body of readSymbols::math_factory.C by simply "return;",
> LyX seems to keep running like a charm.
>
> Aparently the use of variables in that particular body of readSymbols
> makes the
Andre,
I think I got a bit closer to the culprit!
Step by step I zoomed in on what the SIGSEGV is causing.
In src/mathed/math_factory.C
readSymbols() calls math_font_available(tmp.inset)
math_font_available() calls augmentFont(f, name)
augmentFont() calls searchFont(name)
Then I
On Thu, Jun 27, 2002 at 06:40:27PM +0900, R. Lahaye wrote:
> Then I get stuck, but when I replace the body of
> math_support.C::searchFont() merely by
>
>fontinfo * searchFont(string const & name)
>{
> return [8];
>}
>
> the problem is solved.
> Are you having any idea what
Andre Poenitz wrote:
Other things to try:
- add an empty line at the back of lib/symbols
- check for empty string 'line' after getline in math_factory.C:189
( if (line.empty())
continue;
just beofre the contruction of the istringstream
Done that, to no avail.
I noticed that
On Wed, Jun 26, 2002 at 06:27:11PM +0900, R. Lahaye wrote:
I noticed that my configure output says:
checking whether the systems std::string is really good... no
Is that of any relevance?
Maybe. Try to configure --with-included-strings
The output from lyx -dbg MATHED is then:
[...]
Andre Poenitz wrote:
Try to configure --with-included-strings
No, that doesn't help !?!
When I do configure --with-included-strings, the output says:
[...]
checking whether the included std::string should be used... checking ... no
checking whether the systems std::string is really
On Thu, Jun 27, 2002 at 11:10:43AM +0900, R. Lahaye wrote:
What happens at the end of readSymbols::math_factory.C and why only
on my FreeBSD PC does this end with a SIGSEGV?
There happens nothing special. Only destructors of the automatic variables
are run. As I said, I guess your heap is
Andre Poenitz wrote:
>
> Other things to try:
>
> - add an empty line at the back of lib/symbols
> - check for empty string 'line' after getline in math_factory.C:189
> ( if (line.empty())
> continue;
>just beofre the contruction of the istringstream
Done that, to no avail.
I
On Wed, Jun 26, 2002 at 06:27:11PM +0900, R. Lahaye wrote:
> I noticed that my configure output says:
> checking whether the systems std::string is really good... no
> Is that of any relevance?
Maybe. Try to configure --with-included-strings
> The output from "lyx -dbg MATHED" is then:
>
>
Andre Poenitz wrote:
>
> Try to configure --with-included-strings
No, that doesn't help !?!
When I do "configure --with-included-strings", the output says:
[...]
checking whether the included std::string should be used... checking ... no
checking whether the systems std::string is really
On Thu, Jun 27, 2002 at 11:10:43AM +0900, R. Lahaye wrote:
> What happens at the end of readSymbols::math_factory.C and why only
> on my FreeBSD PC does this end with a SIGSEGV?
There happens nothing special. Only destructors of the automatic variables
are run. As I said, I guess your heap is
Andre Poenitz wrote:
On Tue, Jun 25, 2002 at 01:31:47PM +0900, R. Lahaye wrote:
lyx -dbg MATHED provides the attached output.
This is the expected output, most of it coming from reading lib/symbol.
It just looks fine.
This comes from simpy do File-New and the click on the mathed
On Tue, Jun 25, 2002 at 03:36:50PM +0900, R. Lahaye wrote:
What compiler, what machine was that?
FreeBSD 4.5-RELEASE i386 / GNU project C and C++ Compiler (gcc-2.95.3)
I have the same compiler, Linux though, but that should really make no
difference.
On another Linux (Mandrake 8.0) PC the
Andre Poenitz wrote:
>
> On Tue, Jun 25, 2002 at 01:31:47PM +0900, R. Lahaye wrote:
> > "lyx -dbg MATHED" provides the attached output.
>
> This is the expected output, most of it coming from reading lib/symbol.
>
> It just looks fine.
>
> > This comes from simpy do "File->New" and the click
On Tue, Jun 25, 2002 at 03:36:50PM +0900, R. Lahaye wrote:
> > What compiler, what machine was that?
>
> FreeBSD 4.5-RELEASE i386 / GNU project C and C++ Compiler (gcc-2.95.3)
I have the same compiler, Linux though, but that should really make no
difference.
> On another Linux (Mandrake 8.0)
On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote:
CVS 1.3.0 as of June 19th. Do following:
1. Start LyX
2. File - New
3. Insert mathed with, for example, the math tool
kaboom: SIGSEGV!!
There seems to be some problem with the dependency tracking for
recompilation. I've
Andre Poenitz wrote:
On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote:
CVS 1.3.0 as of June 19th. Do following:
1. Start LyX
2. File - New
3. Insert mathed with, for example, the math tool
kaboom: SIGSEGV!!
There seems to be some problem with the dependency
Andre Poenitz wrote:
On Mon, Jun 24, 2002 at 05:24:50PM +0900, R. Lahaye wrote:
There seems to be some problem with the dependency tracking for
recompilation. I've seen similar and a clean recompile helped.
Nope.
The SIGSEGV persist after a make maintainer-clean and even after
On Tue, Jun 25, 2002 at 01:31:47PM +0900, R. Lahaye wrote:
lyx -dbg MATHED provides the attached output.
This is the expected output, most of it coming from reading lib/symbol.
It just looks fine.
This comes from simpy do File-New and the click on the mathed icon
on the icon-taskbar.
On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote:
> CVS 1.3.0 as of June 19th. Do following:
>
> 1. Start LyX
> 2. File -> New
> 3. Insert mathed with, for example, the math tool
>
> kaboom: SIGSEGV!!
There seems to be some problem with the dependency tracking for
recompilation.
Andre Poenitz wrote:
>
> On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote:
> > CVS 1.3.0 as of June 19th. Do following:
> >
> > 1. Start LyX
> > 2. File -> New
> > 3. Insert mathed with, for example, the math tool
> >
> > kaboom: SIGSEGV!!
>
> There seems to be some problem with
Andre Poenitz wrote:
>
> On Mon, Jun 24, 2002 at 05:24:50PM +0900, R. Lahaye wrote:
> > > There seems to be some problem with the dependency tracking for
> > > recompilation. I've seen similar and a clean recompile helped.
> >
> > Nope.
> >
> > The SIGSEGV persist after a "make maintainer-clean"
On Tue, Jun 25, 2002 at 01:31:47PM +0900, R. Lahaye wrote:
> "lyx -dbg MATHED" provides the attached output.
This is the expected output, most of it coming from reading lib/symbol.
It just looks fine.
> This comes from simpy do "File->New" and the click on the mathed icon
> on the
Hi,
Andre', is this bug related to your mathed-stuff?
The bug, as mentioned before in
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg39632.html
was there also some time ago; see, for example:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg39127.html
Andre', you fixed it
Hi,
Andre', is this bug related to your mathed-stuff?
The bug, as mentioned before in
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg39632.html
was there also some time ago; see, for example:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg39127.html
Andre', you fixed it
Hi,
CVS 1.3.0 as of June 19th. Do following:
1. Start LyX
2. File - New
3. Insert mathed with, for example, the math tool
kaboom: SIGSEGV!!
---
The gdb backtrace is:
Program received signal SIGSEGV, Segmentation
Hi,
CVS 1.3.0 as of June 19th. Do following:
1. Start LyX
2. File -> New
3. Insert mathed with, for example, the math tool
kaboom: SIGSEGV!!
---
The gdb backtrace is:
Program received signal SIGSEGV, Segmentation
54 matches
Mail list logo
