Am 16.10.2014 um 23:16 schrieb S. Razi Alavizadeh:
> Hello Adam,
>
> I just saw Leon has updated the thread [1].
>
> Is the correct way to test, compiling qpdfview (revision before
> modified djvu model) with the new libredjvu and see if it crashes?
Yes, this sounds like the way to go.
Best regards, Adam.
> [1]
> http://sourceforge.net/p/djvu/discussion/103286/thread/e5172b1c/#1910/e253/4ae4/35a1/f48b/704e/0896/3465/0119
>
> Best Regards, Razi.
>
> 2014-10-01 23:24 GMT+03:30 Adam Reichold
> <email address hidden>:
>
>> Hello Razi,
>>
>> as discussed with Leon in DjVuLibre forum, we will need to
>> serialize access to all DjVuLibre API (at least in its current
>> version) using objects of type "miniexp_t". Why this has never
>> affected Linux, nobody knows, but I'll add the necessary global
>> mutex to trunk. Could you give a try running Windows?
>>
>> Best regards, Adam.
>>
>> P.S.: We introduced an out-of-bounds access in
>> "DjVuPage::search", i.e. we could call "word.at(index)" if "index
>> == word.length()". Should be fixed as well.
>>
>> ** Summary changed:
>>
>> - Search within multiple DjVu files. + Crash when searching
>> within multiple DjVu files
>>
>> -- You received this bug notification because you are subscribed
>> to the bug report. https://bugs.launchpad.net/bugs/1370540
>>
>> Title: Crash when searching within multiple DjVu files
>>
>> Status in qpdfview: Triaged
>>
>> Bug description: Steps to reproduce: 1- Open more than two DjVu
>> that you know have the text you trying to search. 2- Write the
>> string you want to search if search-line edit and use SHIFT+Enter
>> to start search within all opened documents. 3- Crash!! 4-
>> There's no problem when at most one DjVu document is opened.
>>
>> Call stack from WinDbg: ntdll!RtlpNtSetValueKey+0x12b
>> ntdll!RtlpNtSetValueKey+0x2914 ntdll!RtlpNtSetValueKey+0x31c5
>> ntdll!LdrSetAppCompatDllRedirectionCallback+0x11442
>> MSVCR100!free+0x1c
>> libdjvulibre!DJVU::GExceptionHandler::operator=+0x5e
>> libdjvulibre!miniobj_t::destroy+0xc
>> libdjvulibre!miniexp_symbol+0x564
>> libdjvulibre!ddjvu_document_get_outline+0x39b
>> libdjvulibre!ddjvu_document_get_outline+0x43d
>> libdjvulibre!ddjvu_document_get_outline+0x43d
>> libdjvulibre!ddjvu_document_get_pagetext+0x1c9
>> qpdfview_djvu!qt_plugin_instance+0x24b4
>> ntdll!RtlAllocateHeap+0xc6
>> QtCore4!QAbstractEventDispatcher::QAbstractEventDispatcher+0x39
>> qpdfview+0x18a16 QtCore4!QThread::setPriority+0x3a3
>> QtCore4!QString::toStdWString+0x1b3b MSVCR100!endthreadex+0xe4
>> ntdll!RtlCreateMemoryZone+0x9b ntdll!RtlCaptureContext+0xeb
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/qpdfview/+bug/1370540/+subscriptions
>>
>
>
Hello Razi,
Am 16.10.2014 um 23:16 schrieb S. Razi Alavizadeh:
> Hello Adam,
>
> I just saw Leon has updated the thread [1].
>
> Is the correct way to test, compiling qpdfview (revision before
> modified djvu model) with the new libredjvu and see if it crashes?
Yes, this sounds like the way to go.
Best regards, Adam.
> [1] sourceforge. net/p/djvu/ discussion/ 103286/ thread/ e5172b1c/ #1910/e253/ 4ae4/35a1/ f48b/704e/ 0896/3465/ 0119 /bugs.launchpad .net/bugs/ 1370540 ValueKey+ 0x12b ValueKey+ 0x2914 ntdll!RtlpNtSet ValueKey+ 0x31c5 CompatDllRedire ctionCallback+ 0x11442 DJVU::GExceptio nHandler: :operator= +0x5e miniobj_ t::destroy+ 0xc miniexp_ symbol+ 0x564 ddjvu_document_ get_outline+ 0x39b ddjvu_document_ get_outline+ 0x43d ddjvu_document_ get_outline+ 0x43d ddjvu_document_ get_pagetext+ 0x1c9 djvu!qt_ plugin_ instance+ 0x24b4 teHeap+ 0xc6 QAbstractEventD ispatcher: :QAbstractEvent Dispatcher+ 0x39 QThread: :setPriority+ 0x3a3 QString: :toStdWString+ 0x1b3b MSVCR100! endthreadex+ 0xe4 MemoryZone+ 0x9b ntdll!RtlCaptur eContext+ 0xeb /bugs.launchpad .net/qpdfview/ +bug/1370540/ +subscriptions
> http://
>
> Best Regards, Razi.
>
> 2014-10-01 23:24 GMT+03:30 Adam Reichold
> <email address hidden>:
>
>> Hello Razi,
>>
>> as discussed with Leon in DjVuLibre forum, we will need to
>> serialize access to all DjVuLibre API (at least in its current
>> version) using objects of type "miniexp_t". Why this has never
>> affected Linux, nobody knows, but I'll add the necessary global
>> mutex to trunk. Could you give a try running Windows?
>>
>> Best regards, Adam.
>>
>> P.S.: We introduced an out-of-bounds access in
>> "DjVuPage::search", i.e. we could call "word.at(index)" if "index
>> == word.length()". Should be fixed as well.
>>
>> ** Summary changed:
>>
>> - Search within multiple DjVu files. + Crash when searching
>> within multiple DjVu files
>>
>> -- You received this bug notification because you are subscribed
>> to the bug report. https:/
>>
>> Title: Crash when searching within multiple DjVu files
>>
>> Status in qpdfview: Triaged
>>
>> Bug description: Steps to reproduce: 1- Open more than two DjVu
>> that you know have the text you trying to search. 2- Write the
>> string you want to search if search-line edit and use SHIFT+Enter
>> to start search within all opened documents. 3- Crash!! 4-
>> There's no problem when at most one DjVu document is opened.
>>
>> Call stack from WinDbg: ntdll!RtlpNtSet
>> ntdll!RtlpNtSet
>> ntdll!LdrSetApp
>> MSVCR100!free+0x1c
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> libdjvulibre!
>> qpdfview_
>> ntdll!RtlAlloca
>> QtCore4!
>> qpdfview+0x18a16 QtCore4!
>> QtCore4!
>> ntdll!RtlCreate
>>
>> To manage notifications about this bug go to:
>> https:/
>>
>
>