#306 coolreader build crashes at startup

[BensonBear]

I have just built coolreader on my 64 bit Fedora 19 system (basically, close to latest version of everything). It did not build at first because the CMakeList.txt file for crengine appeared to be missing some references, but after putting them in in built fine and ran fine.

But on my 32 bit Fedora 19 system (netbook) it builds okay but crashes as soon as it is run. It appears to have problems with the cache it creates in .cr3.

Here is a stacktrace:

    0  0x080ebd90 in ldomDataStorageManager::getStyleData(unsigned int, ldomNodeStyleInfo*) ()
    #1  0x080ec2b8 in ldomNode::getFont() ()
    #2  0x080efd86 in ldomDocument::checkRenderContext() ()
    #3  0x080f90a9 in ldomDocument::render(LVRendPageList*, LVDocViewCallback*, int, int, bool, int, LVProtectedFastRef<lvfont>, int, LVFastRef<crpropaccessor>) ()
    #4  0x08147f13 in LVDocView::Render(int, int, LVRendPageList*) ()
    #5  0x0814807a in LVDocView::checkRender() ()
    #6  0x0814c464 in LVDocView::updateBookMarksRanges() ()
    #7  0x0815d764 in LVDocView::propsApply(LVFastRef<crpropaccessor>) ()
    #8  0x0809ac31 in CR3View::loadSettings(QString) ()
    #9  0x080a3b76 in MainWindow::MainWindow(QWidget*) ()
    #10 0x08087fbb in main ()


I include a copy of cr3 --loglevel=TRACE as an attachment (Can someone say how at this site one includes a scrolling code section in a message?)


</crpropaccessor></crpropaccessor></lvfont>

[BensonBear]

I have been trying to trace this code without really understanding it in order to determine why it is crashing.

I've tracked it down to this so far: when a chunk is retrieved with getChunk, but it has a null buffer _buf (since it was saved to file), ensureunpacked calls restorefromcache to get it back, but when it calls compact right after this, it seems that this sets the _buf back to null again. I can get it to work by just commenting out the one call to compact in ensureunpacked.

It seems that getchunk sets _recentchunk to the chunk it is called with, and then right away after it calls ensureunpacked on this chunk, compact is called again and starts writing out chunks starting with _recentchunk, so chunk becomes null again.

I must be reading this wrong because it does seem to work on my other machine.

Perhaps it is because of the processing on addresses and the difference between 32 and 64 bit addresses in the two architectures

[BensonBear]

Aargh, I found the problem, it is something careless I did. I should have checked the build commands very carefully for the two different machines. Somehow, on the one, I deleted a few chars on the cmake line and defined DOC_BUFFER_SIZE as 0x14000 instead of 0x1400000. No doubt that took it outside of a (not clearly specified) legitimate range. Because of my carelessness here I had to track this down the very long and hard way...