Alfredo Braunstein wrote:
> I think something along the lines of the (completely untested) attached
> patch should be enough to get rid of the crashes. The destruction
> signaling machinery should not be needed anymore. Comments?
Feel free to test and/or apply, possibly with the removal of the si
Abdelrazak Younes wrote:
>>> Right but this case would be detected by an assertion whereas using an
>>> invalid inset pointer will crash LyX very badly.
>>
>> What assertion? (I mean where in the code).
>
> When you access a pos or pit greater than the size of the paragraph or
> the size of the
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
fixIfBroken). But I don't really understand why you think the signal
solution is bad. This is the *only* way to ensure that the inset pointer
inside CursorSlice is valid at any time. Even wi
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Of course I think that all this is not very relevant because
Alfredo> the right solution would be to avoid the iterators being
Alfredo> invalid in the first place. As a side note, I wished really
Alfredo> stable iterators f
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Abdelrazak Younes wrote:
>>
>>> fixIfBroken). But I don't really understand why you think the signal
>>> solution is bad. This is the *only* way to ensure that the inset pointer
>>> inside CursorSlice is valid at any time. Even with Alfredo
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
fixIfBroken). But I don't really understand why you think the signal
solution is bad. This is the *only* way to ensure that the inset pointer
inside CursorSlice is valid at any time. Even with Alfredo solution you
could end up with an invalid p
Abdelrazak Younes wrote:
> fixIfBroken). But I don't really understand why you think the signal
> solution is bad. This is the *only* way to ensure that the inset pointer
> inside CursorSlice is valid at any time. Even with Alfredo solution you
> could end up with an invalid pointer if you forgot
Alfredo Braunstein wrote:
Bo Peng wrote:
I guess I need a more detailed description to reproduce it...
abcdefgh1w
Now do whatever is necessary in your environmet to switch back to the
first window.
I see. I need to remove enough chars to make pos > size in the old window.
I think something
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Bo Peng wrote:
>>> > > I guess I need a more detailed description to reproduce it...
>>>
>>> abcdefgh1w
>>>
>>> Now do whatever is necessary in your environmet to switch back to
>>> the first window.
>> I see. I need to
Bo Peng wrote:
>> >
>> > I guess I need a more detailed description to reproduce it...
>>
>> abcdefgh1w
>>
>> Now do whatever is necessary in your environmet to switch back to the
>> first window.
>
> I see. I need to remove enough chars to make pos > size in the old window.
I think something al
>
> I guess I need a more detailed description to reproduce it...
abcdefgh1w
Now do whatever is necessary in your environmet to switch back to the
first window.
I see. I need to remove enough chars to make pos > size in the old window.
Bo
On Thu, May 31, 2007 at 02:41:06PM -0500, Bo Peng wrote:
> >#3785 now.
>
> I guess I need a more detailed description to reproduce it...
abcdefgh1w
Now do whatever is necessary in your environmet to switch back to the
first window.
Backtrace:
[New Thread -1227621488 (LWP 12202)]
wrong pos 8, m
Bo Peng wrote:
#3785 now.
I guess I need a more detailed description to reproduce it...
It will crash in debug mode only. The only thing to fix and complement
is DocIterator::fixIfBroken() in order to cover all cases. Some of the
test done there are not correct as Alfredo has already noticed.
#3785 now.
I guess I need a more detailed description to reproduce it...
Bo
On Thu, May 31, 2007 at 12:43:04PM -0500, Bo Peng wrote:
> >> At last someone who don't think I've compromised LyX cleanness for
> >> eternity :-)
> >
> >My dog doesn't either.
>
> Please register your bug to bugzilla and mark it as critical so that
> Abdel can have a look;
#3785 now.
Andre'
On Thu, May 31, 2007 at 12:43:04PM -0500, Bo Peng wrote:
> >> At last someone who don't think I've compromised LyX cleanness for
> >> eternity :-)
> >
> >My dog doesn't either.
>
> Please register your bug to bugzilla and mark it as critical so that
> Abdel can have a look; or sit down and impleme
Andre Poenitz wrote:
On Thu, May 31, 2007 at 02:25:57PM +0200, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote: Possibly yes. I have a patch
Abdelrazak> pending for that issue that is not
> At last someone who don't think I've compromised LyX cleanness for
> eternity :-)
My dog doesn't either.
Please register your bug to bugzilla and mark it as critical so that
Abdel can have a look; or sit down and implement your Alfredo way and
demonstrate to us that your method is better.
It
On Thu, May 31, 2007 at 06:11:25PM +0200, Abdelrazak Younes wrote:
> Bo Peng wrote:
> >>OK, as this is a fix to a crash and that it also addresses Andre' main
> >>complaint about the memory consumption due to the boost::signal in the
> >>Inset class I'll commit.
> >
> >I have no opinion on the use
On Thu, May 31, 2007 at 02:25:57PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >>"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> >Abdelrazak> Jean-Marc Lasgouttes wrote: Possibly yes. I have a patch
> >Abdelrazak> pending for that issue that is not OKed A
> I have no opinion on the use of signals in inset.
At last someone who don't think I've compromised LyX cleanness for
eternity :-)
Actually, I though of the singal approach when I implement
onMouseHover. If you still remember the crashes when the last_inset_
in BufferView became invalid when a
Bo Peng wrote:
OK, as this is a fix to a crash and that it also addresses Andre' main
complaint about the memory consumption due to the boost::signal in the
Inset class I'll commit.
I have no opinion on the use of signals in inset.
At last someone who don't think I've compromised LyX cleannes
OK, as this is a fix to a crash and that it also addresses Andre' main
complaint about the memory consumption due to the boost::signal in the
Inset class I'll commit.
I have no opinion on the use of signals in inset. Just to report that
lyx does not crash now with this revision.
Cheers,
Bo
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote: Possibly yes. I have a patch
Abdelrazak> pending for that issue that is not OKed AFAIS. Could you
Abdelrazak> try it?
I tried this one but cannot compile:
Abdel
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote: Possibly yes. I have a patch
Abdelrazak> pending for that issue that is not OKed AFAIS. Could you
Abdelrazak> try it?
>> I tried this one but cannot compile:
>>
Abdelrazak> Sorry, try thi
Jean-Marc Lasgouttes wrote:
Abdelrazak> Possibly yes. I have a patch pending for that issue that
Abdelrazak> is not OKed AFAIS. Could you try it?
I tried this one but cannot compile:
Sorry, try this one.
Abdel.
Index: CursorSlice.cpp
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> I cannot reproduce this in (current) rev18579.
Bo> I find that removal of every collapsable inset leads to crash.
Bo> Must be something that is introduced recently.
Bo> E.g. insert ERT, enter a, move cursor to the right, backspace, lyx
Bo> cr
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Bo Peng wrote:
>> On 5/30/07, Bo Peng <[EMAIL PROTECTED]> wrote:
>>> > >> I find that removal of every collapsable inset leads to
>>> crash. Must be > >> something that is introduced recently.
>> Abdel,
>>
>> It is s
Bo Peng wrote:
It is suspected that your destroyed() signal crashes lyx in this case,
maybe a problem with my gcc 3.4.6. I remember that a similar crash
that is only reproducible on gcc 3.4 was fixed by adding disconnect()
somewhere a while ago. Maybe this is the case again.
FYI, lyx compiled wi
Bo Peng wrote:
On 5/30/07, Bo Peng <[EMAIL PROTECTED]>
wrote:
> >> I find that removal of every collapsable inset leads to crash.
Must be
> >> something that is introduced recently.
Abdel,
It is suspected that your destroyed() signal crashes lyx in this case,
maybe a problem with my gcc 3.4.
It is suspected that your destroyed() signal crashes lyx in this case,
maybe a problem with my gcc 3.4.6. I remember that a similar crash
that is only reproducible on gcc 3.4 was fixed by adding disconnect()
somewhere a while ago. Maybe this is the case again.
FYI, lyx compiled with gcc4 does no
On 5/30/07, Bo Peng <[EMAIL PROTECTED]> wrote:
> >> I find that removal of every collapsable inset leads to crash. Must be
> >> something that is introduced recently.
Abdel,
It is suspected that your destroyed() signal crashes lyx in this case,
maybe a problem with my gcc 3.4.6. I remember tha
>> I find that removal of every collapsable inset leads to crash. Must be
>> something that is introduced recently.
I randomly revert to r18530, crash, r18500 no crash. I roughly
remember that we upgraded boost at that time...
Bo
Richard Heck wrote:
> Bo Peng wrote:
>
>>> I cannot reproduce this in (current) rev18579.
>>>
>> I find that removal of every collapsable inset leads to crash. Must be
>> something that is introduced recently.
>>
>> E.g. insert ERT, enter a, move cursor to the right, backspace, lyx
>> cra
Bo Peng wrote:
>> I cannot reproduce this in (current) rev18579.
> I find that removal of every collapsable inset leads to crash. Must be
> something that is introduced recently.
>
> E.g. insert ERT, enter a, move cursor to the right, backspace, lyx
> crashes.
>
> I am using r18579, under linux.
I'
As for the other problem: no crash here (WinXP)
I can also confirm that lyx/win works fine. Can any linux people
confirm this? Note that I am using a 64bit machine.
Cheers,
Bo
Bo Peng schrieb:
I cannot reproduce this in (current) rev18579.
I find that removal of every collapsable inset leads to crash. Must be
something that is introduced recently.
E.g. insert ERT, enter a, move cursor to the right, backspace, lyx crashes.
As for the other problem: no crash here
I cannot reproduce this in (current) rev18579.
I find that removal of every collapsable inset leads to crash. Must be
something that is introduced recently.
E.g. insert ERT, enter a, move cursor to the right, backspace, lyx crashes.
I am using r18579, under linux.
Bo
Bo Peng schrieb:
Start a new article, choose beamer layout, write a, select, edit->text
style -> alert, move cursor before it, delete, lyx crashes with the
following backtrace:
I cannot reproduce this in (current) rev18579.
Bernhard
Start a new article, choose beamer layout, write a, select, edit->text
style -> alert, move cursor before it, delete, lyx crashes with the
following backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182907542720 (LWP 9472)]
0x in ?? ()
(gdb) back
40 matches
Mail list logo
