Am Donnerstag, 20. April 2017 um 23:48:12, schrieb Scott Kostyshak <skost...@lyx.org> > 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 > > <skost...@lyx.org> > > > 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.
