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.