[Okular-devel] TextDocument Multithreading

Thu Sep 26 18:41:05 UTC 2013

On Thu, Sep 26, 2013 at 11:50 PM, Jaydeep Solanki <jaydp17 at gmail.com> wrote:

> I have created a small project, uploaded to git at git.kde.org:
> scratch/jsolanki/TxtDocumentTest01
>
may be u'll get a permission denied error when configuring,
*fix :* either run cmake as root or change the install_prefix and run
configure again.

May be there's a better way to do what I'm doing with CMake but I'm not so
good at it, thus did something that requires little bit of change but works.

>
> May be you'd like to have a look at it.
> I have (extracted and) uploaded the file that made it crash the most, to
> data folder in that repo.
>
> & It doesn't crash.
>
>
> On Wed, Sep 25, 2013 at 11:48 PM, Jaydeep Solanki <jaydp17 at gmail.com>wrote:
>
>>
>>
>>
>> On Wed, Sep 25, 2013 at 11:40 PM, Albert Astals Cid <aacid at kde.org>wrote:
>>
>>> El Dimecres, 25 de setembre de 2013, a les 23:19:11, Jaydeep Solanki va
>>> escriure:
>>> > On Wed, Sep 25, 2013 at 11:01 PM, Jaydeep Solanki <jaydp17 at gmail.com>
>>> wrote:
>>> > > Running it under helgrind, gives
>>> > > this<https://www.dropbox.com/s/5v3bh1v6le8adkr/helg.txt>output.
>>> > >
>>> > > It shows a warning near the region where we get a crash saying
>>> "*conflicts
>>> > > with a previous write of size 4 by thread #4*", L117 in helgrind
>>> output
>>> > > file
>>> > >
>>> > > Also, can you please throw some light on what the warning is trying
>>> to
>>> > > say. What is a 'conflict on previous write' ?
>>> >
>>> > I read the documentation and understood what it is, but it doesn't
>>> give any
>>> > insight about what's going wrong.
>>> >
>>> > BTW, I tried a few times with helgrind & it didn't crash.
>>>
>>> Yeah, it may go so slow that it doesn't really race/crash itself.
>>>
>>> I am betting on saying "this is a bug in Qt" but let's prove it first ;-)
>>>
>>> My suggestion, do this: Write a simple program that spawns two threads,
>>> in
>>> each thread you create a QTextDocument, add some text to it and then
>>> simply
>>> loop its rendering to a QImage forever.
>>>
>>> Let's see if that crashes or not. If not, we can build up from there
>>> trying to
>>> make it more like what Okular does until it crashes.
>>>
>>> You up to it?
>>>
>> Yes
>>
>>>
>>> Cheers,
>>>   Albert
>>>
>>> >
>>> > > On Mon, Sep 23, 2013 at 1:40 PM, Jaydeep Solanki <jaydp17 at gmail.com
>>> >wrote:
>>> > >> On Mon, Sep 23, 2013 at 3:17 AM, Albert Astals Cid <aacid at kde.org>
>>> wrote:
>>> > >>> El Dilluns, 23 de setembre de 2013, a les 02:05:23, Jaydeep
>>> Solanki va
>>> > >>>
>>> > >>> escriure:
>>> > >>> > On Sun, Sep 22, 2013 at 9:21 PM, Albert Astals Cid <
>>> aacid at kde.org>
>>> > >>>
>>> > >>> wrote:
>>> > >>> > > El Dissabte, 21 de setembre de 2013, a les 23:16:56, Jaydeep
>>> Solanki
>>> > >>>
>>> > >>> va
>>> > >>>
>>> > >>> > > escriure:
>>> > >>> > > > On Sat, Sep 21, 2013 at 9:25 PM, Albert Astals Cid <
>>> aacid at kde.org>
>>> > >>> > >
>>> > >>> > > wrote:
>>> > >>> > > > > El Dissabte, 21 de setembre de 2013, a les 14:50:50,
>>> Jaydeep
>>> > >>>
>>> > >>> Solanki
>>> > >>>
>>> > >>> > > > > va
>>> > >>> > > > >
>>> > >>> > > > > escriure:
>>> > >>> > > > > > Hi,
>>> > >>> > > > >
>>> > >>> > > > > Hi
>>> > >>> > > > >
>>> > >>> > > > > > @Albert,
>>> > >>> > > > > > Welcome back :)
>>> > >>> > > > >
>>> > >>> > > > > Thanks :-)
>>> > >>> > > > >
>>> > >>> > > > > > As you might be aware GSoC is coming to an end, I want
>>> to wrap
>>> > >>> > > > > > things
>>> > >>> > > > > > up.
>>> > >>> > > > > >
>>> > >>> > > > > > I have a few days, and I want to finish multi-threading
>>> > >>>
>>> > >>> support for
>>> > >>>
>>> > >>> > > > > > ePubs
>>> > >>> > > > > > before GSoC ends. I have created a patch, but it crashes
>>> > >>>
>>> > >>> sometimes,
>>> > >>>
>>> > >>> > > I'm
>>> > >>> > >
>>> > >>> > > > > > unable to find a reason to that.
>>> > >>> > > > >
>>> > >>> > > > > Where's the patch?
>>> > >>> > > >
>>> > >>> > > > Diff attached
>>> > >>> > > >
>>> > >>> > > > File to test on :
>>> > >>> > > > link<
>>> > >>>
>>> > >>>
>>> https://www.dropbox.com/s/x63kkjf8q4h4fdy/Getting%20Gold%20by%20J_C_F_J
>>> > >>>
>>> > >>> > > > ohnson.epub>
>>> > >>> > > >
>>> > >>> > > > > Do you have a backtrace of the crash?
>>> > >>> > > >
>>> > >>> > > > I have got two different backtraces, using the same ePub
>>> > >>> > > >
>>> > >>> > > > Backtrace 1 : http://paste.kde.org/p0b9a1e1e/
>>> > >>> > > >
>>> > >>> > > > Backtrace 2 : http://paste.kde.org/pa4e31b12/
>>> > >>> > >
>>> > >>> > > Any reason you have not installed debug symbols for Qt to get a
>>> > >>>
>>> > >>> better
>>> > >>>
>>> > >>> > > bracktrace (less ??)?
>>> > >>> >
>>> > >>> > Installed it.
>>> > >>> > still I'm not able to make any sense out of it.
>>> > >>> >
>>> > >>> > Updated backtrace :  http://paste.kde.org/pa8f27933/
>>> > >>>
>>> > >>> How are you getting the backtrace?
>>> > >>
>>> > >> I use Qt Creator, when it crashes I use create full backtrace
>>> option to
>>> > >> get this backtrace.
>>> > >> Further more using gdb + terminal I get
>>> > >> this<http://paste.kde.org/p11fad1cf/>backtrace.
>>> > >>
>>> > >> Can you mark in which thread the crash is
>>> > >>
>>> > >>> happening?
>>> > >>
>>> > >> I get an ABORT signal when
>>> TextDocumentGeneratorPrivate::createTextPage(.
>>> > >> . .) is called inside core/textdocumentgenerator.cpp. Now inside
>>> that 99%
>>> > >> of the times I get a crash on L81 (my branch).
>>> > >>
>>> > >>> Cheers,
>>> > >>>
>>> > >>>   Albert
>>> > >>>
>>> > >>> > > Cheers,
>>> > >>> > >
>>> > >>> > >   Albert
>>> > >>> > >
>>> > >>> > > > > What has changed
>>> > >>> > > > > since last time we tried to do this?
>>> > >>> > > >
>>> > >>> > > > I have noticed that it only crashes when the epub has an
>>> adequate
>>> > >>>
>>> > >>> amount
>>> > >>>
>>> > >>> > > of
>>> > >>> > >
>>> > >>> > > > images. Epubs with no images or 1 or 2 images are less
>>> likely to
>>> > >>>
>>> > >>> crash.
>>> > >>>
>>> > >>> > > The
>>> > >>> > >
>>> > >>> > > > more the images the more likely it is to crash.
>>> > >>> > > >
>>> > >>> > > > Now we don't have to guess if it will crash on this file or
>>> not.
>>> > >>> > > > Considering all this, I have given you an ePub that is most
>>> likely
>>> > >>>
>>> > >>> to
>>> > >>>
>>> > >>> > > crash
>>> > >>> > >
>>> > >>> > > > atleast once before completing a round trip (top to bottom &
>>> > >>>
>>> > >>> bottom to
>>> > >>>
>>> > >>> > > > top).
>>> > >>> > > >
>>> > >>> > > > > Cheers,
>>> > >>> > > > >
>>> > >>> > > > >   Albert
>>> > >>> > > > >
>>> > >>> > > > > > So, can we please help, me get this done.
>>> > >>> > > > > > It's the same bug that we once tried to fix on IRC.
>>> > >>> > > > > >
>>> > >>> > > > > > I'll be available on #okular, same time as usual.
>>> > >>> > > > > >
>>> > >>> > > > > > Cheers,
>>> > >>> > > > > > Jaydeep
>>> > >>> > > > >
>>> > >>> > > > > _______________________________________________
>>> > >>> > > > > Okular-devel mailing list
>>> > >>> > > > > Okular-devel at kde.org
>>> > >>> > > > > https://mail.kde.org/mailman/listinfo/okular-devel
>>> > >>> > >
>>> > >>> > > _______________________________________________
>>> > >>> > > Okular-devel mailing list
>>> > >>> > > Okular-devel at kde.org
>>> > >>> > > https://mail.kde.org/mailman/listinfo/okular-devel
>>> > >>>
>>> > >>> _______________________________________________
>>> > >>> Okular-devel mailing list
>>> > >>> Okular-devel at kde.org
>>> > >>> https://mail.kde.org/mailman/listinfo/okular-devel
>>>
>>> _______________________________________________
>>> Okular-devel mailing list
>>> Okular-devel at kde.org
>>> https://mail.kde.org/mailman/listinfo/okular-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20130927/2d140e02/attachment.html>