-
Notifications
You must be signed in to change notification settings - Fork 1
Quickly open PDF in new tab & close freezes tab #4
Comments
You should definitely work as a software tester ;-). You're doing a good job. The bug you mentioned is related to a unlucky resource clean up order. I will push the commit with the fix in a few minutes. |
Haha thanks :-) I will keep reporting any issues I can provoke...
on the call stack. |
Since changing the resource clean up order I can't reproduce this bug anymore. Can you please install the debugging symbols for okular (usually packagename-dbg in Debian flavoured systems) and provide a full backtrace when this bug happens again? |
Here's the backtrace:
When I interrupt it a second time, it's locking the mutex, above it was unlocking it.
And a third interruption. This time, some event handling is going on, but it's still sitting in closeDocument():
|
Looks like this is a race condition in Okular. Still can't reproduce the bug, what makes it extremely hard to track down. The following patch is just a random shot, but maybe it fixes this issue:
|
Nope, doesn't fix it, now it freezes at m_part->closeURL(). I also think this is a problem in Okular... do you know if the document open and closeUrl() are called from the same thread? Are you testing on a machine with multi-core support (mine has 2 cores + hyperthreading)? |
Okay, would have been too easy :). The both methods openDocument() and closeDocument() are called from the same thread. I set some breakpoints to verify this. This means the speedy chromium is not the cause ;-). My assumption is, that m_executingPixmapRequests.isEmpty() always returns false and because of that the execution stucks in that do-while-loop (document.cpp:1781): bool startEventLoop = false;
do
{
d->m_pixmapRequestsMutex.lock();
startEventLoop = !d->m_executingPixmapRequests.isEmpty();
d->m_pixmapRequestsMutex.unlock();
if ( startEventLoop )
{
d->m_closingLoop = &loop;
loop.exec();
d->m_closingLoop = 0;
}
}
while ( startEventLoop ); So the question is: Why does m_executingPixmapRequests get emptied in some cases and in others not? Looks like we're testing nearly on the same hardware. Mine has a Core i7 with 2 cores and 2 virtual cores for hyperthreading. |
I'm afraid but there's another race (Chromium)... :(
When I open a PDF which opens in a new tab and immediately close the tab (while it's still loading) with okularplugin using Ctrl+W, the first tab freezes (you may have to try this a couple of times). This does not happen if there's at least one more okularplugin tab open, so it's probably related to the cleanup that's done when the last plugin container gets destroyed.
The text was updated successfully, but these errors were encountered: