On 07/02/2014 04:29 PM, Paul A. Rubin wrote:
Scott Kostyshak lyx.org> writes:
On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes
lyx.org> wrote:
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
The other possibility is to loo
Scott Kostyshak lyx.org> writes:
>
> On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes
lyx.org> wrote:
> > Le 02/07/14 17:07, Richard Heck a écrit :
> >
> >> There was a report from someone who did not have autosave enabled.
> >
> >
> > The other possibility is to look at changes that occurr
On 07/02/2014 03:40 PM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
Maybe there are two different triggers? When I find some time, I'll play a
bit with autosave.
The other report c
Jean-Marc Lasgouttes wrote:
> Le 02/07/14 17:07, Richard Heck a écrit :
>> There was a report from someone who did not have autosave enabled.
Maybe there are two different triggers? When I find some time, I'll play a
bit with autosave.
> The other possibility is to look at changes that occurred
Richard Heck wrote:
> On 07/01/2014 04:36 PM, Georg Baum wrote:
>> Richard Heck wrote:
>>
>>> That was what I was thinking, too. Just guessing at this point.
>> Yes. It would be really nice if we had a more reliable way to reproduce
>> the crash. OTOH it is good that it does not occur very often;-
On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes wrote:
> Le 02/07/14 17:07, Richard Heck a écrit :
>
>> There was a report from someone who did not have autosave enabled.
>
>
> The other possibility is to look at changes that occurred in Tabular code.
> The main difference that I see is new s
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
The other possibility is to look at changes that occurred in Tabular
code. The main difference that I see is new support for
insert/duplicate-row. Do we have indications that people ha
On 07/01/2014 04:36 PM, Georg Baum wrote:
Richard Heck wrote:
That was what I was thinking, too. Just guessing at this point.
Yes. It would be really nice if we had a more reliable way to reproduce the
crash. OTOH it is good that it does not occur very often;-)
I went over the code again and
On 07/01/2014 04:50 PM, Georg Baum wrote:
Richard Heck wrote:
That was what I was thinking, too. Just guessing at this point.
Another wild guess: Since the backtrace shows autoSave(), and autoSave()
runs in a separate thread and operates on the cloned buffer: Could the non-
thread-safety of th
Richard Heck wrote:
> That was what I was thinking, too. Just guessing at this point.
Another wild guess: Since the backtrace shows autoSave(), and autoSave()
runs in a separate thread and operates on the cloned buffer: Could the non-
thread-safety of the cloning business be the real problem? At
Richard Heck wrote:
> That was what I was thinking, too. Just guessing at this point.
Yes. It would be really nice if we had a more reliable way to reproduce the
crash. OTOH it is good that it does not occur very often;-)
I went over the code again and found and fixed a memory leak (and missing
On 07/01/2014 02:38 PM, Georg Baum wrote:
Richard Heck wrote:
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since
"\begin_inset
smells little bit lik
Richard Heck wrote:
> On 06/30/2014 06:54 PM, Pavel Sanda wrote:
>> Richard Heck wrote:
>>> Paragraph::write, so the crashing call to to_utf8 could come in any of
>>> them. The crashing call certainly isn't the first one, since
>>> "\begin_inset
>> smells little bit like concurrency problem inside
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave
Richard Heck wrote:
> Paragraph::write, so the crashing call to to_utf8 could come in any of
> them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave while using to_utf8 somewhere in ui?
p
Richard Heck wrote:
> The key part is:
>
> #15 0x00a99af0 in lyx::to_utf8(std::basic_string #std::char_traits, std::allocator > const&) ()
> No symbol table info available.
> #16 0x005c6577 in lyx::Paragraph::write(std::ostream&,
> #lyx::BufferParams const&, unsigned long&) const
Not sure how important it is, but looking at
#15 0x00a99af0 in lyx::to_utf8(std::basic_stringstd::char_traits, std::allocator > const&) ()
#16 0x005c6577 in lyx::Paragraph::write(std::ostream&,
lyx::BufferParams const&, unsigned long&) const ()
#17 0x005ed142 in lyx::Te
On 06/29/2014 08:06 AM, Jean-Marc Lasgouttes wrote:
What is thé contents of thé truncated document ?
Here's a longer backtrace:
#0 0x00a99af0 in lyx::to_utf8(std::basic_string,
std::allocator > const&) ()
No symbol table info available.
#1 0x005c6577 in lyx::Paragraph::write
What is thé contents of thé truncated document ?
JMarc
On 29 juin 2014 13:01:08 UTC+02:00, "José Matos" wrote:
>Hi,
> a fedora user submitted the following report
>https://bugzilla.redhat.com/show_bug.cgi?id=1114263
>
>I hope that some of the debug information provided helps to find the
>c
Hi,
a fedora user submitted the following report
https://bugzilla.redhat.com/show_bug.cgi?id=1114263
I hope that some of the debug information provided helps to find the cause of
the crash. :-(
Regards,
--
José Abílio
21 matches
Mail list logo
