On 04/24/2011 06:02 AM, Edwin Leuven wrote:
Richard Heck:
What the usual calls to updateBuffer() do is always
make the macro context a ParIterator that points to
the first paragraph in the current inset. (See e.g.
the calls at InsetText:682,695.)
ok. makes me wonder though why it is necessary t
Richard Heck :
> What the usual calls to updateBuffer() do is always
> make the macro context a ParIterator that points to
> the first paragraph in the current inset. (See e.g.
> the calls at InsetText:682,695.)
ok. makes me wonder though why it is necessary to set the macro
context explicitly.
>
Il 23/04/2011 19:52, Edwin Leuven ha scritto:
Richard Heck wrote:
I guess the other idea would be to recurse
through all the insets.
attached, and no more crashes.
i think i prefer this solution (although i am not sure we need to add
the code to insettext)
ed.
FYI, I just added a test-case
On 04/23/2011 02:07 PM, John McCabe-Dansted wrote:
On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuven wrote:
..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false
VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188
In case this is relevant, this assertion also shows up in:
http://gmat
Regarding the x2.patch, the problem is that par_iterator_begin() does
not give us a "complete" DocIterator (one starting with the Buffer's own
InsetText, etc), which is what we need. I am constantly running into
this problem!
Regarding the other patch, adding the code to InsetText just seeme
On Sat, Apr 23, 2011 at 11:45 PM, Edwin Leuven wrote:
> ..\..\..\lyx-devel\src\support\lassert.cpp(21): ASSERTION false
> VIOLATED IN ..\..\lyx-devel\src\CursorSlice.cpp:188
In case this is relevant, this assertion also shows up in:
http://gmatht.homelinux.net/xp/keytest/html_out/out/t18//html/
Richard Heck wrote:
> I guess the other idea would be to recurse
> through all the insets.
attached, and no more crashes.
i think i prefer this solution (although i am not sure we need to add
the code to insettext)
ed.
x3.patch
Description: Binary data
Richard Heck wrote:
> Can you post this version of the patch
> and I'll try to have a look?
attached
> I'm wondering where these comparisons are
> being made and whether we need to do
> something to the cursor. But I'm really
> just guessing here.
very frustating this poking in the dark...
> I
On 04/23/2011 11:45 AM, Edwin Leuven wrote:
I wonder if we could try:
ParagraphList::const_iterator pit =
tail.getText(0)->paragraphs().begin();
buffer().updateBuffer(pit, OutputUpdate);
i am not sure i completely follow you, but when i use
buffer().updateBuffer(par_iterator_begin(tai
On 04/23/2011 11:45 AM, Edwin Leuven wrote:
I wonder if we could try:
ParagraphList::const_iterator pit =
tail.getText(0)->paragraphs().begin();
buffer().updateBuffer(pit, OutputUpdate);
i am not sure i completely follow you, but when i use
buffer().updateBuffer(par_iterator_begin(tai
Richard Heck wrote:
> My main comment would be that I suspect, but of course
> couldn't verify, due to the crashes, that the same
> problem exists in the TexRow() output routine,
i checked that previewing the document and having the source view pane
open worked
my guess was that things are ok as
On 04/23/2011 06:56 AM, Edwin Leuven wrote:
Richard Heck wrote:
Answer: No, probably not, because it's hard to see
how to do this without making copies, which would
just give us the same problem back again.
the attached avoids the crash for me by setting the macrocontext for
nested insets (and
Richard Heck wrote:
> Answer: No, probably not, because it's hard to see
> how to do this without making copies, which would
> just give us the same problem back again.
the attached avoids the crash for me by setting the macrocontext for
nested insets (and only doing the metrics call on the tail;
On 04/22/2011 10:42 PM, Richard Heck wrote:
On 04/22/2011 05:24 PM, Edwin Leuven wrote:
Richard Heck wrote:
I think I know what's happening here.
sounds reasonable indeed
We might somehow need to call updateBuffer()
on these new insets.
or find a way of calculating the width of the insette
On 04/22/2011 05:24 PM, Edwin Leuven wrote:
Richard Heck wrote:
I think I know what's happening here.
sounds reasonable indeed
We might somehow need to call updateBuffer()
on these new insets.
or find a way of calculating the width of the insettext before and
after the decimal separator wit
Richard Heck wrote:
> I think I know what's happening here.
sounds reasonable indeed
> We might somehow need to call updateBuffer()
> on these new insets.
or find a way of calculating the width of the insettext before and
after the decimal separator without making a copy, chopping it into
two a
On 04/22/2011 02:17 PM, Richard Heck wrote:
On 04/22/2011 01:46 PM, Edwin Leuven wrote:
Richard Heck wrote:
Same crash with a footnote there. So it looks
as if for some reason insets inside cells are not
getting their macro context set properly.
which is done in lines 3453-3473 of insettabula
On 04/22/2011 01:46 PM, Edwin Leuven wrote:
Richard Heck wrote:
Same crash with a footnote there. So it looks
as if for some reason insets inside cells are not
getting their macro context set properly.
which is done in lines 3453-3473 of insettabular.cpp:
if (tabular.getAlignment(cell) == LY
Richard Heck wrote:
> Same crash with a footnote there. So it looks
> as if for some reason insets inside cells are not
> getting their macro context set properly.
which is done in lines 3453-3473 of insettabular.cpp:
if (tabular.getAlignment(cell) == LYX_ALIGN_DECIMAL) {
// make a copy
On 04/22/2011 01:36 PM, Richard Heck wrote:
On 04/22/2011 12:01 PM, Edwin Leuven wrote:
assert in textmetrics.cpp line 395
when i scoll down (or use toc) to table 5 in this doc:
http://dl.dropbox.com/u/359550/peerng.lyx
a broken document, just when i switch to trunk for real work :(
The caus
On 04/22/2011 12:01 PM, Edwin Leuven wrote:
assert in textmetrics.cpp line 395
when i scoll down (or use toc) to table 5 in this doc:
http://dl.dropbox.com/u/359550/peerng.lyx
a broken document, just when i switch to trunk for real work :(
The cause is the InsetScript in that table. If you re
assert in textmetrics.cpp line 395
when i scoll down (or use toc) to table 5 in this doc:
http://dl.dropbox.com/u/359550/peerng.lyx
a broken document, just when i switch to trunk for real work :(
ed.
1. insert figure float
2. click on its label via middle mouse button.
3. kaboom
Program received signal SIGABRT, Aborted.
0xe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xe410 in __kernel_vsyscall ()
#1 0xb705d101 in raise () from /lib/libc.so.6
#2 0xb705e8e8 in abort () from /lib/libc.so.6
Strangely, I seem only to be getting this on one machine. But nonetheless:
#0 __gnu_debug::_Safe_iterator<__gnu_norm::_Bit_iterator,
__gnu_debug_def::vector > >::_M_is_end
(this=0x7fff8e4ec660) at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_base.h:104
#1 0
> Pavel Sanda wrote:
>> Open math manual.
>> Ctrl+F and Find next "Because all"
>> Toggle Search backwards
>> Twice push Find next button
>> Kaboom!
>>
> Can't reproduce this one
difficult to reproduce, when its already fixed :D
pavel
Pavel Sanda wrote:
Open math manual.
Ctrl+F and Find next "Because all"
Toggle Search backwards
Twice push Find next button
Kaboom!
Can't reproduce this one
[EMAIL PROTECTED] ~]$ uname -r && rpm -q qt4
2.6.23.15-137.fc8
qt4-4.3.3-1.fc8
rh
> Fixed in r23354.
thanks
pavel
Fixed in r23354.
Stefan
Am 29.02.2008 um 16:02 schrieb Pavel Sanda:
Open math manual.
Ctrl+F and Find next "Because all"
Toggle Search backwards
Twice push Find next button
Kaboom!
Backtraces make life easier:
#4 0x95f756f9 in __gnu_debug::_Error_formatter::_M_error ()
#5 0x00114512 in
__gnu_debug
::_Safe_iterator<__gnu_cxx::__normal_iterator__gnu_norm::vector > >,
__gnu_debug_def::vector >
>::operator-> (this=0xbfffce04) at safe_iterator.h:191
#6 0x00113182 in ly
Open math manual.
Ctrl+F and Find next "Because all"
Toggle Search backwards
Twice push Find next button
Kaboom!
Am 25.02.2008 um 11:25 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
What did you do to make this happen?
1) new document
2) type "lalalala l"
3) type "a"
Works fine here. Even using stdlib-debug.
Stefan
Stefan Schimanski wrote:
What did you do to make this happen?
1) new document
2) type "lalalala l"
3) type "a"
Abdel.
lyx.exe!std::char_traits::assign(unsigned long &
_Left=3452816845, const unsigned long & _Right=) Line 173 + 0x6
bytes C++
lyx.exe!std::char_traits::_Copy_s(unsigned long *
_First1=0x10560040, unsigned int _Dest_size=28716311, const unsigned
long * _First2=0x01b81000, unsigned int _Count
lyx.exe!std::char_traits::assign(unsigned long &
_Left=3452816845, const unsigned long & _Right=) Line 173 + 0x6 bytes C++
lyx.exe!std::char_traits::_Copy_s(unsigned long *
_First1=0x10560040, unsigned int _Dest_size=28716311, const unsigned
long * _First2=0x01b81000, unsigned int _Count=28
rgheck wrote:
Andre Poenitz wrote:
On Thu, Feb 21, 2008 at 11:32:28AM -0500, rgheck wrote:
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
Index: insets/InsetLayout.h
===
--- inset
Andre Poenitz wrote:
On Thu, Feb 21, 2008 at 11:32:28AM -0500, rgheck wrote:
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
Index: insets/InsetLayout.h
===
--- insets/InsetLayo
On Thu, Feb 21, 2008 at 11:32:28AM -0500, rgheck wrote:
> Andre Poenitz wrote:
>> On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
>>
>>> Index: insets/InsetLayout.h
>>> ===
>>> --- insets/InsetLayout.h(revision 230
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
Index: insets/InsetLayout.h
===
--- insets/InsetLayout.h(revision 23079)
+++ insets/InsetLayout.h(working copy)
@@ -23,6 +23,12 @@
Andre Poenitz wrote:
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
Index: insets/InsetLayout.h
===
--- insets/InsetLayout.h(revision 23079)
+++ insets/InsetLayout.h(working copy)
@@ -23,6 +23,12 @@
On Wed, Feb 20, 2008 at 03:08:03PM -0500, Richard Heck wrote:
> Index: insets/InsetLayout.h
> ===
> --- insets/InsetLayout.h (revision 23079)
> +++ insets/InsetLayout.h (working copy)
> @@ -23,6 +23,12 @@
> ///
> class Inse
Richard Heck wrote:
What we need here seems to me to be a hardcoded empty InsetLayout,
similar to the hardcoded empty layout introduced into TextClass. This
already kind of exists in TextClass::insetlayout(), though it isn't
available if we don't have a TextClass. So I've made it static in the
Abdelrazak Younes wrote:
This happens while trying to open any of the help documents.
Richard maybe?
OK. This was caused by my commits---so my bad---but I think it's because
I exposed an underlying bug. I've fixed it for now, in the sense that
the help documents will open. The problem was tha
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
This happens while trying to open any of the help documents.
Richard maybe?
lyx.exe!lyx::Paragraph::isFreeSpacing() Line 2373 + 0x27
bytesC++
By the way d->inset_owner_ is an InsetFoot here if that makes any
difference.
Yes, p
Abdelrazak Younes wrote:
This happens while trying to open any of the help documents.
Richard maybe?
lyx.exe!lyx::Paragraph::isFreeSpacing() Line 2373 + 0x27 bytesC++
By the way d->inset_owner_ is an InsetFoot here if that makes any
difference.
Abdel.
This happens while trying to open any of the help documents.
Richard maybe?
lyx.exe!lyx::Paragraph::isFreeSpacing() Line 2373 + 0x27 bytes C++
lyx.exe!lyx::`anonymous namespace'::readParToken(const lyx::Buffer &
buf={...}, lyx::Paragraph & par={...}, lyx::Lexer & lex={...}, const
s
Andre Poenitz wrote:
On Tue, Feb 19, 2008 at 08:32:30AM +0100, Abdelrazak Younes wrote:
rgheck wrote:
Do something to lyx2lyx to cause a syntax error. Now try to open a file
that needs converting. BOOM!
Does this help? Of course inset_iterator_begin() should not crash to begin
with.
Author:
On Tue, Feb 19, 2008 at 08:32:30AM +0100, Abdelrazak Younes wrote:
> rgheck wrote:
>> Do something to lyx2lyx to cause a syntax error. Now try to open a file
>> that needs converting. BOOM!
>
> Does this help? Of course inset_iterator_begin() should not crash to begin
> with.
>
> Author: younes
>
rgheck wrote:
Do something to lyx2lyx to cause a syntax error. Now try to open a file
that needs converting. BOOM!
Does this help? Of course inset_iterator_begin() should not crash to
begin with.
Author: younes
Date: Tue Feb 19 08:31:02 2008
New Revision: 23063
URL: http://www.lyx.org/tra
Do something to lyx2lyx to cause a syntax error. Now try to open a file
that needs converting. BOOM!
Backtrace:
#0 0x003c41430ec5 in raise (sig=) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x003c41432970 in abort () at abort.c:88
#2 0x003c47458cf7 in __gnu_debug::_Error_
On Thu, Jan 10, 2008 at 02:22:52PM -0500, rgheck wrote:
> Andre Poenitz wrote:
>> On Thu, Jan 10, 2008 at 01:45:23AM -0500, rgheck wrote:
>>
>>> When lyx2lyx fails with an error:
>>> gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb
>>>
>>
>> Completely unrelated out o
Andre Poenitz wrote:
On Thu, Jan 10, 2008 at 01:45:23AM -0500, rgheck wrote:
When lyx2lyx fails with an error:
gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb
Completely unrelated out of interest: Why do you use --interpreter=mi2?
It does not give any advantages
On Thu, Jan 10, 2008 at 01:45:23AM -0500, rgheck wrote:
>
> When lyx2lyx fails with an error:
> gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb
Completely unrelated out of interest: Why do you use --interpreter=mi2?
It does not give any advantages when used 'manually', does
rgheck wrote:
Abdelrazak Younes wrote:
Please see if this helps:
URL: http://www.lyx.org/trac/changeset/22473
I'll test it tomorrow. Time for bed
Fine. Time to really work for me ;-)
Abdel.
Abdelrazak Younes wrote:
Please see if this helps:
URL: http://www.lyx.org/trac/changeset/22473
I'll test it tomorrow. Time for bed
rh
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Happened while it was just sitting there. I've seen this several
times.
But this doesn't look like a sane backtrace, did you forgot to type bt?
As non-sane as it may look, that's exactly what I go
Abdelrazak Younes wrote:
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Happened while it was just sitting there. I've seen this several
times.
But this doesn't look like a sane backtrace, did you forgot to type bt?
As non-sane as it may look, that's exactly what I got when I typed
rgheck wrote:
Abdelrazak Younes wrote:
rgheck wrote:
Happened while it was just sitting there. I've seen this several times.
But this doesn't look like a sane backtrace, did you forgot to type bt?
As non-sane as it may look, that's exactly what I got when I typed bt.
OK.
It seems that t
rgheck wrote:
When lyx2lyx fails with an error:
...
#3 0x0072b269 in lyx::CursorSlice::paragraph (this=optimized out>) at
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/vector:192
It looks like the DocIterator::slices_ is empty and 'DocIterator::top()'
Abdelrazak Younes wrote:
rgheck wrote:
Happened while it was just sitting there. I've seen this several times.
But this doesn't look like a sane backtrace, did you forgot to type bt?
As non-sane as it may look, that's exactly what I got when I typed bt.
It seems that these scrollbar actions
rgheck wrote:
Happened while it was just sitting there. I've seen this several times.
But this doesn't look like a sane backtrace, did you forgot to type bt?
Abdel.
When lyx2lyx fails with an error:
gdb /cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quiet(gdb) quitgdb
/cvs/lyx-devel/trunk/src/lyx --interpreter=mi2 -quietQuit
(gdb) quitquit
The program is running. Exit anyway? (y or n) [answered Y; input not
from terminal]
(gdb) Process exited
gdb /cvs/
Happened while it was just sitting there. I've seen this several times.
#0 0x003c41430ec5 in raise () from /lib64/libc.so.6
#1 0x003c41432970 in abort () from /lib64/libc.so.6
#2 0x003c4142a11f in __assert_fail () from /lib64/libc.so.6
#3 0x003db224acd9 in QAbstractItemView::
Abdelrazak Younes wrote:
> Yes, that was it.
confirmed.
> I don't know if this is applicable to 1.5.
The problem does not occur in branch.
Jürgen
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
- new document
- type "abc"
- return (generate empty paragraph)
- click between a and b with the mouse
I think this is because the BufferView Cursor is not up to date at the
time of the drawing (in BufferView::checkDepm()). But it is weird th
Jürgen Spitzmüller wrote:
- new document
- type "abc"
- return (generate empty paragraph)
- click between a and b with the mouse
I think this is because the BufferView Cursor is not up to date at the
time of the drawing (in BufferView::checkDepm()). But it is weird that
1.5 is not affected by
- new document
- type "abc"
- return (generate empty paragraph)
- click between a and b with the mouse
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2b0dffde0780 (LWP 5953)]
0x004d4ff8 in lyx::Paragraph::size (this=0x133ee80) at
Paragraph.cpp:2656
2656pos
Abdelrazak Younes wrote:
Dov Feldstern wrote:
Dov Feldstern wrote:
Hi!
Deleting the last word in a paragraph causes a crash (tested in
r21082). It looks like it's related to FontList?
Reading this over, I realize that my description of the problem is not
at all clear: the crash occurs wh
Alfredo Braunstein wrote:
Angus Leeming wrote:
Abdelrazak Younes wrote:
PS: Sorry Angus but you deserved it ;-)
PPS: I'm talking about Rugby...
Me too. So did you.
:-)
Viva Argentina ;-)
Abdel.
Angus Leeming wrote:
> Abdelrazak Younes wrote:
>> PS: Sorry Angus but you deserved it ;-)
>> PPS: I'm talking about Rugby...
>
> Me too. So did you.
:-)
A/
Abdelrazak Younes wrote:
> PS: Sorry Angus but you deserved it ;-)
> PPS: I'm talking about Rugby...
Me too. So did you.
Dov Feldstern wrote:
Dov Feldstern wrote:
Hi!
Deleting the last word in a paragraph causes a crash (tested in
r21082). It looks like it's related to FontList?
Reading this over, I realize that my description of the problem is not
at all clear: the crash occurs when deleting the last remai
Dov Feldstern wrote:
Dov Feldstern wrote:
Hi!
Deleting the last word in a paragraph causes a crash (tested in
r21082). It looks like it's related to FontList?
Reading this over, I realize that my description of the problem is not
at all clear: the crash occurs when deleting the last remai
Dov Feldstern wrote:
Hi!
Deleting the last word in a paragraph causes a crash (tested in r21082).
It looks like it's related to FontList?
Reading this over, I realize that my description of the problem is not
at all clear: the crash occurs when deleting the last remaining
character in a p
Hi!
Deleting the last word in a paragraph causes a crash (tested in r21082).
It looks like it's related to FontList?
Here's the trace:
#0 0xb7129d86 in raise () from /lib/libc.so.6
#1 0xb712b5b1 in abort () from /lib/libc.so.6
#2 0xb72c2436 in __gnu_debug::_Error_formatter::_M_error ()
"Leuven, E." <[EMAIL PROTECTED]> writes:
> PS if you wonder why i am fiddling with ctrl-w: i was tricked by my
> french (azerty) keyboard with US international bindings...
I know this feeling...
JMarc
Leuven, E. wrote:
ctrl-n
ctrl-w
BOOM!
backtrace below
Oups my fault... side effect of my fix to the disappearing cursor.
I'll correct that.
Abdel.
ctrl-n
ctrl-w
BOOM!
backtrace below
edwin
PS if you wonder why i am fiddling with ctrl-w: i was tricked by my french
(azerty) keyboard with US international bindings...
PPS
> lyx.exe!lyx::support::abort() Line 25 + 0x8 bytes C++
lyx.exe!error_handler(int err_sig=11) Line
this
http://www.lyx.org/trac/changeset/20357
should take care of it...
-Original Message-
From: Jürgen Spitzmüller [mailto:[EMAIL PROTECTED]
Sent: Tue 9/18/07 11:50
To: LyX Devel
Subject: crash in trunk (preferences->converters)
- Go to Preferences->Converters
- Select a con
i'll investigate...
-Original Message-
From: Jürgen Spitzmüller [mailto:[EMAIL PROTECTED]
Sent: Tue 9/18/07 11:50
To: LyX Devel
Subject: crash in trunk (preferences->converters)
- Go to Preferences->Converters
- Select a converter, say LaTeX (plain) -> DVI
- Modify this c
- Go to Preferences->Converters
- Select a converter, say LaTeX (plain) -> DVI
- Modify this converter
- Hit the "Change" button
=> CRASH.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47003240016464 (LWP 19945)]
0x2abfcacbdba8 in std::basic_string,
std::allocator
Bernhard Roider wrote:
1. new document
2. insert a (figure) float
3. press the left cursor key twice (OR press the up key once)
4. press he right cursor key
I've committed a fix for this in rev 19919:
Author: younes
Date: Thu Aug 30 18:48:47 2007
New Revision: 19919
URL: http://www.lyx.org/tr
1. new document
2. insert a (figure) float
3. press the left cursor key twice (OR press the up key once)
4. press he right cursor key
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
BOOM!
Yes, this is an old one.
selecting (multiple) cells is not possible either
Even inserting a single character doesn't work ;-/
this kinda sucks...
Yep.
Abdel.
Abdelrazak Younes wrote:
Edwin Leuven wrote:
BOOM!
Yes, this is an old one.
selecting (multiple) cells is not possible either
this kinda sucks...
Edwin Leuven wrote:
insert table
put cursor in cell
shift + arrow down
BOOM!
Yes, this is an old one. The problem is that the CoordCache is not
correctly reconstructed in the updateMetrics within the table. Some
missing points are not being re-added after the CoordCache has been
cleared in B
insert table
put cursor in cell
shift + arrow down
BOOM!
#0 0xb7398947 in raise () from /lib/tls/libc.so.6
#1 0xb739a0c9 in abort () from /lib/tls/libc.so.6
#2 0x08520f23 in lyx::support::abort () at
../../../lyx-devel/src/support/abort.C:22
#3 0x080c0f18 in boost::assertion_failed (expr=0x8
86 matches
Mail list logo
