Crash when searching within multiple DjVu files

[Razi Alavizadeh]

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

[Adam Reichold (adamreichold)]

Hello Razi,

I just tried to reproduce it using DjVuLibre 3.5.25 running Arch Linux without success. Could this be a problem that is specific to a document, a DjVuLibre version or its Windows port? Because when calling ddjvu_document_get_pagetext, we have not really done anything with the data structure from DjVuLibre yet.

Best regards, Adam.

[Adam Reichold (adamreichold)]

Hello again,

do you have a debug of DjVuLibre available? And do you know whether this
happens on the first iteration through the loop within
"DjVuPage::search"? Have you tried using a single instance of
"ddjvu_context_t"? And locking on the single context instead of the
invidiual documents?

Best regards, Adam.

Am 17.09.2014 um 16:20 schrieb S. Razi Alavizadeh:
> Public bug reported:
>
> 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
>
> ** Affects: qpdfview
> Importance: Undecided
> Status: New
>
>
> ** Tags: djvu search
>

[Razi Alavizadeh (srazi)]

Hello Adam,
Sorry for my late reply I didn't have Internet access.

I also use version DjVuLibre 3.5.25 (from DjView-4.9 Windows installer package).
It seems it is an issue with Windows side, because I tested it with different DjVu files.

> do you have a debug of DjVuLibre available? And do you know whether this
> happens on the first iteration through the loop within
> "DjVuPage::search"? Have you tried using a single instance of
> "ddjvu_context_t"? And locking on the single context instead of the
> invidiual documents?

As I said I didn't compile it by myself, just a release build is available (when I have more free time I'll try to compile it).

No, crash occurs on the second iteration.
I don't know how to apply your suggestion, would you provide a patch or a sudo-code?

But as a workaround I modify SearchTask to be a subclass of QRunnable (indeed copy-paste most of code from RenderTask) and for its thread pool I set max thread count to 1 then it searches documents one by one without crash.

Best Regards,
Razi.

[Adam Reichold (adamreichold)]

Hello Razi,

Am 19.09.2014 um 22:29 schrieb S. Razi Alavizadeh:
> Hello Adam,
> Sorry for my late reply I didn't have Internet access.
>
> I also use version DjVuLibre 3.5.25 (from DjView-4.9 Windows installer package).
> It seems it is an issue with Windows side, because I tested it with different DjVu files.
>
>> do you have a debug of DjVuLibre available? And do you know whether this
>> happens on the first iteration through the loop within
>> "DjVuPage::search"? Have you tried using a single instance of
>> "ddjvu_context_t"? And locking on the single context instead of the
>> invidiual documents?
>
> As I said I didn't compile it by myself, just a release build is
> available (when I have more free time I'll try to compile it).
>
> No, crash occurs on the second iteration.
> I don't know how to apply your suggestion, would you provide a patch or a sudo-code?

The suggestion is similar to what you describe below but more specific
to DjVu documents: In "DjVuPlugin::loadDocument", a new instance of
"ddjvu_context_t" is created for each document and each instance of
DjVuDocument has its own "QMutex" member. My suggestion would be to
store a single instance of "ddjvu_context_t" and "QMutex" within
"DjVuPlugin" and pass that single instance to each created instance of
"DjVuDocument".

> But as a workaround I modify SearchTask to be a subclass of QRunnable
> (indeed copy-paste most of code from RenderTask) and for its thread pool
> I set max thread count to 1 then it searches documents one by one
> without crash.
>
> Best Regards,
> Razi.

Best regards, Adam.

[Razi Alavizadeh (srazi)]

Hello Adam,
Thanks for your suggestion, but when I used a single instance of "ddjvu_context_t" and launched QPDFView, (with two DjVu documents as its last session) the second document (active tab) was loaded with just one page!

But with multiple instances of "ddjvu_context_t" (as current implementation) and just move QMutex to "DjVuPlugin" as you said it fixes this issue. [1]

[1] https://code.launchpad.net/~srazi/qpdfview/fix-multi-search-djvu

Best Regards,
Razi.

[Adam Reichold (adamreichold)]

Hello Razi,

your change fixes the symptom because all DjVu API access is serialize as if there was only a single thread, but not the issue since the problem is most likely within the Windows of DjVuLibre as other platforms can happily render or search pages of different documents and hence contexts in parallel which is a performance improvement I would not miss because of one problematic port. My suggestion was in any case meant to isolate the problem so that we now know that the Windows implemenation of DjVuLibre has a threading problem for text extraction which the POSIX port does not seem to have. (Or our usage of the API is wrong and it works on Linux by pure luck which have no indication for so far.)

Best regards, Adam.

[Razi Alavizadeh (srazi)]

Hello Adam,

> your change fixes the symptom because all DjVu API access is serialize
> as if there was only a single thread

No, maybe I explain it badly, with changes that I pushed yesterday, search
works as expected, i.e. there are parallel searches started on all opened
document without crash.

Best Regards,
Razi.

2014-09-21 19:33 GMT+03:30 Adam Reichold <email address hidden>:

> Hello Razi,
>
> your change fixes the symptom because all DjVu API access is serialize
> as if there was only a single thread, but not the issue since the
> problem is most likely within the Windows of DjVuLibre as other
> platforms can happily render or search pages of different documents and
> hence contexts in parallel which is a performance improvement I would
> not miss because of one problematic port. My suggestion was in any case
> meant to isolate the problem so that we now know that the Windows
> implemenation of DjVuLibre has a threading problem for text extraction
> which the POSIX port does not seem to have. (Or our usage of the API is
> wrong and it works on Linux by pure luck which have no indication for so
> far.)
>
> Best regards, Adam.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1370540
>
> Title:
> Search within multiple DjVu files.
>
> Status in qpdfview:
> Incomplete
>
> 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
>

--
Alavizadeh, Sayed Razi
My Blog: http://pozh.org
Saaghar (نرم‌افزار شعر): http://saaghar.pozh.org/
Saaghar Fan Page: http://www.facebook.com/saaghar.p
Saaghar Mailing List: http://groups.google.com/group/saaghar

[Adam Reichold (adamreichold)]

Hello again,

Am 21.09.2014 um 18:29 schrieb S. Razi Alavizadeh:
> Hello Adam,
>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread
>
>
> No, maybe I explain it badly, with changes that I pushed yesterday, search
> works as expected, i.e. there are parallel searches started on all opened
> document without crash.

No, there are several search tasks running but all of their calls to the
DjVuLibre API are serialized, so they are not really running in parallel
but rather interleaved. And this is then also true for rendering which
is not an acceptable limitation.

Best regards, Adam.

> Best Regards,
> Razi.
>
> 2014-09-21 19:33 GMT+03:30 Adam Reichold <email address hidden>:
>
>> Hello Razi,
>>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread, but not the issue since the
>> problem is most likely within the Windows of DjVuLibre as other
>> platforms can happily render or search pages of different documents and
>> hence contexts in parallel which is a performance improvement I would
>> not miss because of one problematic port. My suggestion was in any case
>> meant to isolate the problem so that we now know that the Windows
>> implemenation of DjVuLibre has a threading problem for text extraction
>> which the POSIX port does not seem to have. (Or our usage of the API is
>> wrong and it works on Linux by pure luck which have no indication for so
>> far.)
>>
>> Best regards, Adam.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1370540
>>
>> Title:
>> Search within multiple DjVu files.
>>
>> Status in qpdfview:
>> Incomplete
>>
>> 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
>>
>
>

[Razi Alavizadeh (srazi)]

Hello again,

> No, there are several search tasks running but all of their calls to the
> DjVuLibre API are serialized, so they are not really running in parallel
> but rather interleaved. And this is then also true for rendering which
> is not an acceptable limitation.

OK, then I think a workaround is using a threadpool with max thread count
set to one on Windows.
But I think for now we can leave it because there are no lots of Windows
users. (maybe just me :D )

Thanks,
Razi.

2014-09-21 20:09 GMT+03:30 Adam Reichold <email address hidden>:

Hello again,

Am 21.09.2014 um 18:29 schrieb S. Razi Alavizadeh:
> Hello Adam,
>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread
>
>
> No, maybe I explain it badly, with changes that I pushed yesterday, search
> works as expected, i.e. there are parallel searches started on all opened
> document without crash.

No, there are several search tasks running but all of their calls to the
DjVuLibre API are serialized, so they are not really running in parallel
but rather interleaved. And this is then also true for rendering which
is not an acceptable limitation.

Best regards, Adam.

> Best Regards,
> Razi.
>
> 2014-09-21 19:33 GMT+03:30 Adam Reichold <email address hidden>:
>
>> Hello Razi,
>>
>> your change fixes the symptom because all DjVu API access is serialize
>> as if there was only a single thread, but not the issue since the
>> problem is most likely within the Windows of DjVuLibre as other
>> platforms can happily render or search pages of different documents and
>> hence contexts in parallel which is a performance improvement I would
>> not miss because of one problematic port. My suggestion was in any case
>> meant to isolate the problem so that we now know that the Windows
>> implemenation of DjVuLibre has a threading problem for text extraction
>> which the POSIX port does not seem to have. (Or our usage of the API is
>> wrong and it works on Linux by pure luck which have no indication for so
>> far.)
>>
>> Best regards, Adam.
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1370540
>>
>> Title:
>> Search within multiple DjVu files.
>>
>> Status in qpdfview:
>> Incomplete
>>
>> 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
>> libdjvulib...

[Adam Reichold (adamreichold)]

Hello,

Am 21.09.2014 um 18:57 schrieb S. Razi Alavizadeh:
> Hello again,
>
>> No, there are several search tasks running but all of their calls to the
>> DjVuLibre API are serialized, so they are not really running in parallel
>> but rather interleaved. And this is then also true for rendering which
>> is not an acceptable limitation.
>
>
> OK, then I think a workaround is using a threadpool with max thread count
> set to one on Windows.
> But I think for now we can leave it because there are no lots of Windows
> users. (maybe just me :D )

As a workaround, yes. But this will have the same implication that all
searching is interleaved even though if you use a different thread pool
than for rendering it will not limit the concurrency of that.

What would probably be most useful in this situation is filing a bug
report with the DjVuLibre project or at least discussing the issue on
their mailing list. (Because maybe it is an API usage error after all.)

Best regards, Adam.

> Thanks,
> Razi.
>
>
> 2014-09-21 20:09 GMT+03:30 Adam Reichold <email address hidden>:
>
> Hello again,
>
> Am 21.09.2014 um 18:29 schrieb S. Razi Alavizadeh:
>> Hello Adam,
>>
>>> your change fixes the symptom because all DjVu API access is serialize
>>> as if there was only a single thread
>>
>>
>> No, maybe I explain it badly, with changes that I pushed yesterday, search
>> works as expected, i.e. there are parallel searches started on all opened
>> document without crash.
>
> No, there are several search tasks running but all of their calls to the
> DjVuLibre API are serialized, so they are not really running in parallel
> but rather interleaved. And this is then also true for rendering which
> is not an acceptable limitation.
>
> Best regards, Adam.
>
>> Best Regards,
>> Razi.
>>
>> 2014-09-21 19:33 GMT+03:30 Adam Reichold <email address hidden>:
>>
>>> Hello Razi,
>>>
>>> your change fixes the symptom because all DjVu API access is serialize
>>> as if there was only a single thread, but not the issue since the
>>> problem is most likely within the Windows of DjVuLibre as other
>>> platforms can happily render or search pages of different documents and
>>> hence contexts in parallel which is a performance improvement I would
>>> not miss because of one problematic port. My suggestion was in any case
>>> meant to isolate the problem so that we now know that the Windows
>>> implemenation of DjVuLibre has a threading problem for text extraction
>>> which the POSIX port does not seem to have. (Or our usage of the API is
>>> wrong and it works on Linux by pure luck which have no indication for so
>>> far.)
>>>
>>> Best regards, Adam.
>>>
>>> --
>>> You received this bug notification because you are subscribed to the bug
>>> report.
>>> https://bugs.launchpad.net/bugs/1370540
>>>
>>> Title:
>>> Search within multiple DjVu files.
>>>
>>> Status in qpdfview:
>>> Incomplete
>>>
>>> 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- Cra...

[Adam Reichold (adamreichold)]

Hello Razi,

were you able to contact the DjVuLibre project on this?

Best regards, Adam.

[Razi Alavizadeh (srazi)]

Hello Adam,
Oops... I had forgot about it! I have already created a new topic here [1].

[1] https://sourceforge.net/p/djvu/discussion/103286/thread/e5172b1c/

Best Regards,
Razi.

2014-09-29 23:57 GMT+03:30 Adam Reichold <email address hidden>:

> Hello Razi,
>
> were you able to contact the DjVuLibre project on this?
>
> Best regards, Adam.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1370540
>
> Title:
> Search within multiple DjVu files.
>
> Status in qpdfview:
> Incomplete
>
> 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
>

--
Alavizadeh, Sayed Razi
My Blog: http://pozh.org
Saaghar (نرم‌افزار شعر): http://saaghar.pozh.org/
Saaghar Fan Page: http://www.facebook.com/saaghar.p
Saaghar Mailing List: http://groups.google.com/group/saaghar

[Razi Alavizadeh (srazi)]

Hello again,
Leon answered to my question, would you please contribute to the discussion there?

Best Regards,
Razi.

[Adam Reichold (adamreichold)]

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.

[Razi Alavizadeh (srazi)]

Hello Adam,

Now it works without crash.

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

Oops, good catch. Thanks for fixing it.

Best Regards,
Razi.

[Razi Alavizadeh (srazi)]

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?

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

--
Alavizadeh, Sayed Razi
My Blog: http://pozh.org
Saaghar (نرم‌افزار شعر): http://saaghar.pozh.org/
Saaghar Fan Page: http://www.facebook.com/saaghar.p
Saaghar Mailing List: http://groups.google.com/group/saaghar

[Adam Reichold (adamreichold)]

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

[Adam Reichold (adamreichold)]

And if it does not crash, a merge request that only conditionally takes these locks based on the DjVuLibre API revision would be most welcome. Thanks!