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 > <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)
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
