Re: SIGSEGV on luatex export #2

[Scott Kostyshak]

On Fri, Apr 21, 2017 at 09:08:36AM +0200, Kornel Benko wrote:
> Am Donnerstag, 20. April 2017 um 23:48:12, schrieb Scott Kostyshak 
> 
> > On Thu, Apr 20, 2017 at 07:59:05PM +0200, Kornel Benko wrote:
> > > Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 
> > > 
> > > > On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > > > > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > > > > A 2nd SIGSEGV, involving similar actions, but the crash happens 
> > > > > > earlier, so
> > > > > > I guess it's a different bug:
> > > > > > 1. clear your ~/.lyx-trunk/cache/*
> > > > > > 2. start LyX, new doc
> > > > > > 3. type "info-insert icon whatevernonsense"
> > > > > > 
> > > > > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > > > > 
> > > > > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a 
> > > > > git
> > > > > bisect tomorrow if no one beats me to it:
> > > > > 
> > > > >   git bisect start
> > > > >   git bisect good 15fd7920
> > > > >   git bisect bad dbcbf305
> > > > 
> > > > My bisect lead to 244de5d2
> > > 
> > > This makes sense, because I came to the same commit while investigating 
> > > the crash.
> > 
> > I'm curious (to improve my debugging skills), how did you think through
> > this and how did the above lead you to 244de5d2?
> 
> From the dbg backtraces I have seen that
>   src/support/FileName.cpp
>   src/graphics/GraphicsConverter.cpp
>   src/graphics/GraphicsCacheItem.cpp
>   src/graphics/GraphicsCacheItem.cpp
> were involved. So I checked with 'git log' for these files if they fit into 
> the interval (15fd7920,dbcbf305)

Nice.

> > > Backtrace gives src/support/FileName.cpp:188
> > >   return d->name
> > > (gdb) p d->name
> > > Cannot access memory at address 0x0
> > 
> > I get to here OK. I think the though process is "why do we crash when
> > reading d->name? Let's print it out". We cannot access the memory, so
> > that means something is wrong with "d->name". Let's go higher up to see
> > where d->name becomes invalid.
> 
> Not only 'd->name' is invalid. The pointer 'd' itself is invalid (zero)

Ah now I see.

> 
> > > (gdb) up
> > >   src/graphics/GraphicsConverter.cpp:146
> > > (gdb) p doc_fname_
> > 
> > Here I am already a little lost. How did you know to print doc_fname_?
> > I see in the gdb output that it is an argument of the function that we
> > are in. But did you just make the connection between the "name" in
> > "d->name" and the "name" in "doc_fname_" ?
> 
> The routine FileName::absFileName() in src/support/FileName.cpp:188 is called 
> without parameter.
> The only call to absFileName() in src/graphics/GraphicsConverter.cpp:146 was
>   doc_fname_.absFileName()
> 
> > > $1 = (const lyx::support::FileName &) @0x3559560: {
> > >   _vptr.FileName = 0x38ca7d0, 
> > >   d = 0x0
> > > }
> > 
> > What information does this tell you? I guess that 0x38ca7d0 is a memory
> > address of the pointer?
> 
> The info is, that the 'd'-value is already here wrong.

Thank you for taking the time to explain all that. I find it very
helpful.

Scott


signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

[Kornel Benko]

Am Freitag, 21. April 2017 um 00:47:38, schrieb Scott Kostyshak 

> On Thu, Apr 20, 2017 at 11:48:12PM -0400, Scott Kostyshak wrote:
> 
> > > $1 = (const lyx::support::FileName &) @0x3559560: {
> > >   _vptr.FileName = 0x38ca7d0, 
> > >   d = 0x0
> > > }
> > 
> > What information does this tell you? I guess that 0x38ca7d0 is a memory
> > address of the pointer?
> 
> Ah so the idea is that at this point I should realize that it should be
> an actual file name, not a pointer to a file name?

The idea is that d should be a pointer to something 'not zero'.
(According to the class FileName it is
private:
Private * const d;
while Private is declared in FileName.cpp:88

but apparently 'd' was never set. (I did not understand why though)
)

> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: SIGSEGV on luatex export #2

[Kornel Benko]

Am Donnerstag, 20. April 2017 um 23:48:12, schrieb Scott Kostyshak 

> On Thu, Apr 20, 2017 at 07:59:05PM +0200, Kornel Benko wrote:
> > Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 
> > 
> > > On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > > > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > > > A 2nd SIGSEGV, involving similar actions, but the crash happens 
> > > > > earlier, so
> > > > > I guess it's a different bug:
> > > > > 1. clear your ~/.lyx-trunk/cache/*
> > > > > 2. start LyX, new doc
> > > > > 3. type "info-insert icon whatevernonsense"
> > > > > 
> > > > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > > > 
> > > > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> > > > bisect tomorrow if no one beats me to it:
> > > > 
> > > >   git bisect start
> > > >   git bisect good 15fd7920
> > > >   git bisect bad dbcbf305
> > > 
> > > My bisect lead to 244de5d2
> > 
> > This makes sense, because I came to the same commit while investigating the 
> > crash.
> 
> I'm curious (to improve my debugging skills), how did you think through
> this and how did the above lead you to 244de5d2?

From the dbg backtraces I have seen that
src/support/FileName.cpp
src/graphics/GraphicsConverter.cpp
src/graphics/GraphicsCacheItem.cpp
src/graphics/GraphicsCacheItem.cpp
were involved. So I checked with 'git log' for these files if they fit into the 
interval (15fd7920,dbcbf305)

> > Backtrace gives src/support/FileName.cpp:188
> > return d->name
> > (gdb) p d->name
> > Cannot access memory at address 0x0
> 
> I get to here OK. I think the though process is "why do we crash when
> reading d->name? Let's print it out". We cannot access the memory, so
> that means something is wrong with "d->name". Let's go higher up to see
> where d->name becomes invalid.

Not only 'd->name' is invalid. The pointer 'd' itself is invalid (zero)

> > (gdb) up
> > src/graphics/GraphicsConverter.cpp:146
> > (gdb) p doc_fname_
> 
> Here I am already a little lost. How did you know to print doc_fname_?
> I see in the gdb output that it is an argument of the function that we
> are in. But did you just make the connection between the "name" in
> "d->name" and the "name" in "doc_fname_" ?

The routine FileName::absFileName() in src/support/FileName.cpp:188 is called 
without parameter.
The only call to absFileName() in src/graphics/GraphicsConverter.cpp:146 was
doc_fname_.absFileName()

> > $1 = (const lyx::support::FileName &) @0x3559560: {
> >   _vptr.FileName = 0x38ca7d0, 
> >   d = 0x0
> > }
> 
> What information does this tell you? I guess that 0x38ca7d0 is a memory
> address of the pointer?

The info is, that the 'd'-value is already here wrong.

> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: SIGSEGV on luatex export #2

[Scott Kostyshak]

On Thu, Apr 20, 2017 at 11:48:12PM -0400, Scott Kostyshak wrote:

> > $1 = (const lyx::support::FileName &) @0x3559560: {
> >   _vptr.FileName = 0x38ca7d0, 
> >   d = 0x0
> > }
> 
> What information does this tell you? I guess that 0x38ca7d0 is a memory
> address of the pointer?

Ah so the idea is that at this point I should realize that it should be
an actual file name, not a pointer to a file name?

Scott


signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

[Scott Kostyshak]

On Thu, Apr 20, 2017 at 07:59:05PM +0200, Kornel Benko wrote:
> Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 
> 
> > On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > > A 2nd SIGSEGV, involving similar actions, but the crash happens 
> > > > earlier, so
> > > > I guess it's a different bug:
> > > > 1. clear your ~/.lyx-trunk/cache/*
> > > > 2. start LyX, new doc
> > > > 3. type "info-insert icon whatevernonsense"
> > > > 
> > > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > > 
> > > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> > > bisect tomorrow if no one beats me to it:
> > > 
> > >   git bisect start
> > >   git bisect good 15fd7920
> > >   git bisect bad dbcbf305
> > 
> > My bisect lead to 244de5d2
> 
> This makes sense, because I came to the same commit while investigating the 
> crash.

I'm curious (to improve my debugging skills), how did you think through
this and how did the above lead you to 244de5d2?

> Backtrace gives src/support/FileName.cpp:188
>   return d->name
> (gdb) p d->name
> Cannot access memory at address 0x0

I get to here OK. I think the though process is "why do we crash when
reading d->name? Let's print it out". We cannot access the memory, so
that means something is wrong with "d->name". Let's go higher up to see
where d->name becomes invalid.

> (gdb) up
>   src/graphics/GraphicsConverter.cpp:146
> (gdb) p doc_fname_

Here I am already a little lost. How did you know to print doc_fname_?
I see in the gdb output that it is an argument of the function that we
are in. But did you just make the connection between the "name" in
"d->name" and the "name" in "doc_fname_" ?

> $1 = (const lyx::support::FileName &) @0x3559560: {
>   _vptr.FileName = 0x38ca7d0, 
>   d = 0x0
> }

What information does this tell you? I guess that 0x38ca7d0 is a memory
address of the pointer?

Scott


signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

[Tommaso Cucinotta]

On 20/04/2017 22:28, Guillaume MM wrote:

The attached fixes it for me.


for me as well, pushed, thanx :-)!

T.

Re: SIGSEGV on luatex export #2

[Guillaume MM]

Le 20/04/2017 à 19:02, Scott Kostyshak a écrit :

On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:

On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:

A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
I guess it's a different bug:
1. clear your ~/.lyx-trunk/cache/*
2. start LyX, new doc
3. type "info-insert icon whatevernonsense"

=> LyX SIGNAL CAUGHT dialog with std::bad_alloc.


I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
bisect tomorrow if no one beats me to it:

  git bisect start
  git bisect good 15fd7920
  git bisect bad dbcbf305


My bisect lead to 244de5d2 but I'm not confident in the bisect (for some
revisions I could reproduce once and then not a separate time. I always
cleared the cache each time but still had mixed results).

When git bisect narrowed in on the commits around there, I thought it
would be 6c920757 since that has to do with icons. But that's not where
bisect took me.

So don't take my results too seriously. Hopefully someone else can take
a look.

Scott



The attached fixes it for me.

You can get a trace for when an exception is thrown in gdb with "catch 
throw".


Guillaume
diff --git a/src/graphics/GraphicsCacheItem.cpp b/src/graphics/GraphicsCacheItem.cpp
index c698168..33d4747 100644
--- a/src/graphics/GraphicsCacheItem.cpp
+++ b/src/graphics/GraphicsCacheItem.cpp
@@ -95,7 +95,7 @@ public:
 	/// The filename we refer too.
 	FileName const filename_;
 	/// The document filename this graphic item belongs to
-	FileName const & doc_file_;
+	FileName doc_file_;
 	///
 	FileMonitor const monitor_;
 
diff --git a/src/graphics/GraphicsConverter.cpp b/src/graphics/GraphicsConverter.cpp
index 55ae246..9e6cbd7 100644
--- a/src/graphics/GraphicsConverter.cpp
+++ b/src/graphics/GraphicsConverter.cpp
@@ -63,7 +63,7 @@ public:
 	SignalType finishedConversion;
 
 	///
-	FileName const & doc_fname_;
+	FileName doc_fname_;
 	///
 	string script_command_;
 	///

Re: SIGSEGV on luatex export #2

[Kornel Benko]

Am Donnerstag, 20. April 2017 um 13:02:32, schrieb Scott Kostyshak 

> On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> > On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > > A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, 
> > > so
> > > I guess it's a different bug:
> > > 1. clear your ~/.lyx-trunk/cache/*
> > > 2. start LyX, new doc
> > > 3. type "info-insert icon whatevernonsense"
> > > 
> > > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> > 
> > I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> > bisect tomorrow if no one beats me to it:
> > 
> >   git bisect start
> >   git bisect good 15fd7920
> >   git bisect bad dbcbf305
> 
> My bisect lead to 244de5d2

This makes sense, because I came to the same commit while investigating the 
crash.
Backtrace gives src/support/FileName.cpp:188
return d->name
(gdb) p d->name
Cannot access memory at address 0x0

(gdb) up
src/graphics/GraphicsConverter.cpp:146
(gdb) p doc_fname_
$1 = (const lyx::support::FileName &) @0x3559560: {
  _vptr.FileName = 0x38ca7d0, 
  d = 0x0
}

(gdb) up
src/graphics/GraphicsConverter.cpp:90

(gdb) p doc_fname
$2 = (const lyx::support::FileName &) @0x3559560: {
  _vptr.FileName = 0x38ca7d0, 
  d = 0x0
}
(gdb) up
(gdb) up
src/graphics/GraphicsCacheItem.cpp:452
(gdb) p doc_file_

$3 = (const lyx::support::FileName &) @0x3559560: {
  _vptr.FileName = 0x38ca7d0, 
  d = 0x0
}
(gdb) up
src/graphics/GraphicsCacheItem.cpp:235


> but I'm not confident in the bisect (for some
> revisions I could reproduce once and then not a separate time. I always
> cleared the cache each time but still had mixed results).
> 
> When git bisect narrowed in on the commits around there, I thought it
> would be 6c920757 since that has to do with icons. But that's not where
> bisect took me.
> 
> So don't take my results too seriously. Hopefully someone else can take
> a look.
> 
> Scott

Kornel

signature.asc
Description: This is a digitally signed message part.

Re: SIGSEGV on luatex export #2

[Tommaso Cucinotta]

On 20/04/2017 19:02, Scott Kostyshak wrote:

My bisect lead to 244de5d2 but I'm not confident in the bisect (for some
revisions I could reproduce once and then not a separate time. I always
cleared the cache each time but still had mixed results).

When git bisect narrowed in on the commits around there, I thought it
would be 6c920757 since that has to do with icons. But that's not where
bisect took me.


perhaps the problem was fixed and later came back ?!?

I'll see whether I can get a decent stack trace...

Thx,

T.

Re: SIGSEGV on luatex export #2

[Scott Kostyshak]

On Thu, Apr 20, 2017 at 04:21:49AM -0400, Scott Kostyshak wrote:
> On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> > A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
> > I guess it's a different bug:
> > 1. clear your ~/.lyx-trunk/cache/*
> > 2. start LyX, new doc
> > 3. type "info-insert icon whatevernonsense"
> > 
> > => LyX SIGNAL CAUGHT dialog with std::bad_alloc.
> 
> I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
> bisect tomorrow if no one beats me to it:
> 
>   git bisect start
>   git bisect good 15fd7920
>   git bisect bad dbcbf305

My bisect lead to 244de5d2 but I'm not confident in the bisect (for some
revisions I could reproduce once and then not a separate time. I always
cleared the cache each time but still had mixed results).

When git bisect narrowed in on the commits around there, I thought it
would be 6c920757 since that has to do with icons. But that's not where
bisect took me.

So don't take my results too seriously. Hopefully someone else can take
a look.

Scott


signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

[Scott Kostyshak]

On Thu, Apr 20, 2017 at 09:10:54AM +0200, Tommaso Cucinotta wrote:
> A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
> I guess it's a different bug:
> 1. clear your ~/.lyx-trunk/cache/*
> 2. start LyX, new doc
> 3. type "info-insert icon whatevernonsense"
> 
> => LyX SIGNAL CAUGHT dialog with std::bad_alloc.

I can reproduce with dbcbf305 and after but not 15fd7920. I can do a git
bisect tomorrow if no one beats me to it:

  git bisect start
  git bisect good 15fd7920
  git bisect bad dbcbf305

Scott


signature.asc
Description: PGP signature

Re: SIGSEGV on luatex export #2

[Tommaso Cucinotta]

A 2nd SIGSEGV, involving similar actions, but the crash happens earlier, so
I guess it's a different bug:
1. clear your ~/.lyx-trunk/cache/*
2. start LyX, new doc
3. type "info-insert icon whatevernonsense"

=> LyX SIGNAL CAUGHT dialog with std::bad_alloc.

T.

On 20/04/2017 09:03, Tommaso Cucinotta wrote:

Hi,

I'm seeing a SIGSEGV in the bug-export-latex-in.txt autotest [1].
Albeit the test doesn't fail, I'm clearly seeing on screen that LyX is showing
the SIGSEGV dialog. Trying a manual repro, it doesn't seem to happen, but
running it in the autotests it does happen all the times.

Anyone might have a clue on what's wrong ?

Thanks,

T.

[1]

TestBegin -dbg files test.lyx > lyx-log.txt 2>&1
KK: \Axinfo-insert icon math-mode\[Return]
KK: \Axbuffer-export luatex\[Return]
KK: \[Tab]\[Return]
TestEnd
Lang C
Assert ! pcregrep -M "support/FileName.cpp .* creating path '/.*/lib/images'" 
lyx-log.txt
Assert ! pcregrep -M 'support/FileName.cpp .* Checksumming 
"/.*/lib/images/.*math-mode.pdf" .*lasted ' lyx-log.txt