> "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 corr
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
> "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
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! w
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 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
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 (fo
"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
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 r
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 m
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 pro
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
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 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 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 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 cor
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 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:
>
> 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 notic
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
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 o
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.
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 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
> a complete fresh do
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 t
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.
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 t
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 faul
28 matches
Mail list logo
