Zim

Text view freeze with a page including a sourceview object

Bug #1460386 reported by ealprr on 2015-05-31
72
This bug affects 12 people
Affects Status Importance Assigned to Milestone
Zim
Medium
Unassigned

Bug Description

The editing frame of Zim freeze while opening a page including a sourceview object.

In log:
DEBUG: Insert object(<TextBuffer object at 0x7fa7eabbe370 (zim+gui+pageview+TextBuffer at 0x1adc6f0)>, <Element 'object' at 0x7fa7eaba6ed0>)
/home/ealprr/projects/zim/zim/gui/widgets.py:188: GtkWarning: gtk_scrolled_window_add(): cannot add non scrollable widget use gtk_scrolled_window_add_with_viewport() instead
  window.add(widget)

I'm using last code from the repository: rev #759.

ealprr (ealprr) on 2015-05-31
description: updated

Bug does not occur on my system, would need a longer error trace to understand what is happening.

REgards,

Jaap

Michael Nix (mchl-nix) wrote :

That also happens to me. See attached screenshot.

Updating the index does refresh the page and makes it work, but after switching to another page those changes are lost and every page with a source view looks similar.

Also note the table of contents on the right. This site also contains text, that is not displayed, but can be selected and manipulated.

These changes are of course only visible after updating the index.

Ryan (ry167) wrote :

I have the same symptoms as Michael.

I have been running it through terminal with -V -D and this shows on pages with Code Blocks:
DEBUG: Insert object(<TextBuffer object at 0x7f6fe3865370 (zim+gui+pageview+TextBuffer at 0x2babd40)>, <Element 'object' at 0x7f6fe3871d20>)

I don't know if that's useful but I can do any additional debugging you ask for

I put a possible fix in revisions 774. Since the issue does not occur here, I can't say positively if it fixes anything, but should at least get rid of the warning you see.

Changed in zim:
status: New → Incomplete
Brendan Kidwell (bkidwell) wrote :

I will test this weekend and report my result.

I have the same problem.

Revision 774 have not fixed it.

I've tried several revisions and found that revision 746 introduced the bug. With rev. 745 sourceview widget works fine.

Also I found that changing
linenumbers="true"
to
linenumbers="false"

in sourceview text snippet prevents sourceview widget from hanging text view.

Hjalmar Boulouednine (mail-xo) wrote :

I must say, that it happens to me only if there is just a liddle bit of content on the page. Something like one CodeBlock and a few lines of Text.

If there are several CodeBlocks on the page, as well as Text and other Stuff, the pages are loading quite well. The CodeBlocks remain in this small size only for about a half second, during the loading of the page.

Hi Alexander,

Thanks for testing, but afraid revision 746 does not touch any code related to this bug, so can't explain at all how that revision would introduce it.

Also playing with the line-numbers does not make the bug appear for me.

Regards,

Jaap

If someone would like to help debugging from source code, please try the following.

Open the files:
- zim/gui/pageview.py
- zim/gui/objectmanager.py

Search for the method name "resize_to_textview"

In both places put a couple of "print" statements (just basic python syntax to get some output)

Run zim from source with "./zim.py --standalone -D" and check for the output of the print statements to show up.

Also try re-sizing the window.

What should happen is that whenever the pageview is resized, the method "resize_to_textview" is called on the sourceview object and the object will resize itself to match the width of the pageview.

First thing I would like to know is whether something goes wrong during this call, or maybe "resize_to_textview" never gets called in the first place... ??

Anyone up for it?

Thanks!

Jaap

Jaap, I have a better idea. I suppose the main obstacle for fixing this issue for fixing this issue is inability to reproduce.

So I've prepared virtual machine image (1.2 GiB) that has the issue
http://self-perfection.homeip.net/files/2015/zim_sourceview_hang_reproduce.ova
I've used VirtualBox to prepare the VM, but the image should be compatible with most common virtual machine players.
User/passw: zim/zim

Just launch zim in vm an try notepad loaded by default.

This vm is basically Debian 8.2 + KDE4 + zim 0.63.

Sorry, but just means extra work for me because I have to figure out how to
install and run a VM - not something I have experience with.

Maybe you could start with just attaching the zim page that shows the issue
- might be in the exact content of the page?

-- Jaap

On Tue, Oct 6, 2015 at 6:42 PM, Alexander Mescheryakov <
<email address hidden>> wrote:

> Jaap, I have a better idea. I suppose the main obstacle for fixing this
> issue for fixing this issue is inability to reproduce.
>
> So I've prepared virtual machine image (1.2 GiB) that has the issue
>
> http://self-perfection.homeip.net/files/2015/zim_sourceview_hang_reproduce.ova
> I've used VirtualBox to prepare the VM, but the image should be compatible
> with most common virtual machine players.
> User/passw: zim/zim
>
> Just launch zim in vm an try notepad loaded by default.
>
> This vm is basically Debian 8.2 + KDE4 + zim 0.63.
>
> --
> You received this bug notification because you are subscribed to Zim.
> https://bugs.launchpad.net/bugs/1460386
>
> Title:
> Text view freeze with a page including a sourceview object
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/zim/+bug/1460386/+subscriptions
>

Here is an example notebook with two pages ("test_sourceview.zip"). Well, it should be self-explanatory.
But I am afraid it won't help. I've this notebook with ubuntu live CD and could not reproduce page view hanging.

Ok, let's try another approach. I've collected full execution trace of zim with problem notebook:
python2 -m trace --timing --ignore-dir=/usr/lib/python2.7 --trace /usr/bin/zim --standalone -D 'Test sourceview hanging'

hang_trace.txt is the part of the trace which is spewed in console upon clicking on hanging page in index tree.

And here is for comparison the part which is belched after clicking on test page which displays sourceview object without hanging.

Succeeded in running the virtual machine - turns out to be easier than I expected to set up :)

Couple of notes:

- resize_to_textview called and runs as expected
- both get_size_request and size_request report the correct number
- for both the hangs and the does-not-hang cases zim does exactly the same
--> so size is set correctly, some error must happen inside the widget or inside the textview object when rendering the widget

- Depends on show-line-numbers --> suggest issue in widget
- When extra line with text is put after the sourceview it works again --> suggest issue in textview
--> no conclusive answer :(

Some more observation:
- Extra text after the sourceview fixes the problem
- Extra whitespace after the sourceview fixes the problem *sometimes* - switching pages quickly sometimes shows the issue, sometimes it don't - reloading the page fixes it again
--> Starting to think it is a timing related issue in the re-draw sequence ??

In the latest revisions I refactored how the embedded objects like sourceview negotiate their size. All implemented according to gtk documentation as far as I can judge.

Still the example in the virtual machine keep showing the same bug :(

Weird thing is, the moment you resize the window or scroll the window it comes unstuck. So the resize and scroll events trigger a re-draw and then everything is fine. Obviously I tried triggering redraw with the standard functions on gtk.Widget, but it has no effect.

So narrowed it down to gtk event sequence, but out of ideas how to nail it.

Anyone feels bored over the weekend, feel free to dive into the gtk event and drawing sequences.

-- Jaap

Changed in zim:
status: Incomplete → Confirmed
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers