release time is coming closer

[Adrian Page]

Bart Coppens wrote:
> On Monday 16 May 2005 14:52, Bart Coppens wrote:
> 
>>Wouldn't this be Select -> Color Range? But it doesn't seem broken to me
>>anymore.
> 
> Why do these things always happen after I press send ;) I can actually crash 
> krita with this: Open an image, select something with it. Then play a bit 
> with undo (I did undo add image as well, no idea if it's related) and redo, 
> and randomly paint on the image with krita. Suddenly, krita crashes :-/ Gdb 
> says:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 21341)]
> 0x41d1879b in KisTiledDataManager::getOldTile(int, int, KisTile*) 
> (this=0x89c1458, col=1, row=1, def=0x8e6a1f0)
>     at kis_tileddatamanager.cc:607
> 607                     tile = m_currentMemento->m_hashTable[tileHash];
> (gdb) bt
> #0  0x41d1879b in KisTiledDataManager::getOldTile(int, int, KisTile*) 
> (this=0x89c1458, col=1, row=1, def=0x8e6a1f0)
>     at kis_tileddatamanager.cc:607
> #1  0x41d195e5 in KisTiledIterator::fetchTileData(int, int) (this=0x8efd828, 
> col=1, row=1) at kis_tilediterator.cc:60
> #2  0x41d16149 in KisTiledHLineIterator (this=0x8efd828, ndevice=0x89c1458, 
> x=120, y=95, w=11, writable=false)
>     at kis_tiledhlineiterator.cc:52
> #3  0x41cfc09b in KisHLineIterator (this=0x8efd828, dm=0x89c1458, x=120, y=95, 
> w=11, writable=false) at kis_iterator.h:73
> #4  0x41cfba2c in KisHLineIteratorPixel (this=0xbfffe7a0, ndevice=0x82d7fc0, 
> dm=0x83086a8, sel_dm=0x89c1458, x=120, y=95,
>     w=11, offsetx=0, offsety=0, writable=true) at kis_iterators_pixel.cc:31
> #5  0x41caddf0 in KisPaintDevice::createHLineIterator(int, int, int, bool) 
> (this=0x82d7fc0, x=120, y=95, w=11,
>     writable=true) at kis_paint_device.cc:687
> #6  0x41ce5008 in KisPainter::bltSelection(int, int, KisCompositeOp const&, 
> KSharedPtr<KisPaintDevice>, unsigned char, int, int, int, int) 
> (this=0x8cf5400, dx=120, dy=95, op=@0xbfffe970, srcdev={ptr = 0x8e8aad0}, 
> opacity=255 '�', sx=0, sy=0,
>     sw=11, sh=11) at kis_painter.cc:363
> #7  0x42671c1f in KisBrushOp::paintAt(KisPoint const&, double, double, double) 
> (this=0x8dee190, pos=@0xbfffeb60,
>     pressure=0.5) at kis_brushop.cc:113
> #8  0x41ce6dfa in KisPainter::paintAt(KisPoint const&, double, double, double) 
> (this=0x8cf5400, pos=@0xbfffeb60,
>     pressure=0.5, xTilt=0, yTilt=0) at kis_painter.cc:765
> #9  0x41d41de5 in KisToolFreehand::paintAt(KisPoint const&, double, double, 
> double) (this=0x84b5108, pos=@0xbfffeb60,
>     pressure=0.5, xTilt=0, yTilt=0) at kis_tool_freehand.cc:209
> #10 0x41d40de1 in KisToolFreehand::buttonPress(KisButtonPressEvent*) 
> (this=0x84b5108, e=0xbfffec00)
>     at kis_tool_freehand.cc:76
> .... less relevant to the crash
> 
> (gdb) bt full
> #0  0x41d1879b in KisTiledDataManager::getOldTile(int, int, KisTile*) 
> (this=0x89c1458, col=1, row=1, def=0x8e6a1f0)
>     at kis_tileddatamanager.cc:607
>         tile = (KisTile *) 0x0
>         tileHash = 33
> #1  0x41d195e5 in KisTiledIterator::fetchTileData(int, int) (this=0x8efd828, 
> col=1, row=1) at kis_tilediterator.cc:60
>         tile = (KisTile *) 0x8e6a1f0
> #3  0x41cfc09b in KisHLineIterator (this=0x8efd828, dm=0x89c1458, x=120, y=95, 
> w=11, writable=false) at kis_iterator.h:73
> No locals.
> #4  0x41cfba2c in KisHLineIteratorPixel (this=0xbfffe7a0, ndevice=0x82d7fc0, 
> dm=0x83086a8, sel_dm=0x89c1458, x=120, y=95,
>     w=11, offsetx=0, offsety=0, writable=true) at kis_iterators_pixel.cc:31
>         i = (KisHLineIterator *) 0x0
> ......
> 
> (gdb) print *m_currentMemento
> $2 = {originator = 0x409105a8, m_hashTable = 0x4201bf5, m_numTiles = 
> 150007384, m_redoHashTable = 0x2,
>   m_delTilesTable = 0x0, m_defPixel = 0x8531460 "\001", m_redoDefPixel = 0x1e 
> <Address 0x1e out of bounds>}
> 
> (gdb) print m_currentMemento -> m_hashTable[33]
> Cannot access memory at address 0x4201c79

I think I know what's happening with these crashes - we're accessing a 
deleted memento, which can happen after an undo if the circumstances are 
right. I have a workaround that seems to be catching these crashes, 
which should let me identify the true cause and the right fix, hopefully 
tomorrow.

Adrian