After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759319 - Crash on "less" resize
Crash on "less" resize
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal critical
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-10 23:03 UTC by Egmont Koblinger
Modified: 2015-12-15 19:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2015-12-10 23:03:17 UTC
Run "less" (on its own, or as part of "man" or "git log" etc.). Resize the window to slightly bigger.

Vte:ERROR:vteaccess.cc:620:void vte_terminal_accessible_text_scrolled(VteTerminal*, gint, gpointer): assertion failed: (i >= 1)

The same error message as in bug 758678, although it became way more frequent than it used to be, so looks like there's a regression somewhere.
Comment 1 Egmont Koblinger 2015-12-11 18:25:56 UTC
3696348c0b9c7d60caf7302411ec4c0298f56e57 is the first bad commit
commit 3696348c0b9c7d60caf7302411ec4c0298f56e57
Author: Christian Persch <chpe@gnome.org>
Date:   Fri Dec 4 20:10:04 2015 +0100

    widget: Rework get_text()
    
    Ignore the passed VteSelectionFunc callback and just always use
    the whole passed range.

:040000 040000 8b7beb4d621909eb20522625d724d50edbc422ae 6bdd1bf89bdef0f0b41412340395df6941f94275 M	src
Comment 2 Christian Persch 2015-12-11 20:09:30 UTC
Hmm so it's due to this change:

-		else if (is_selected(m_terminal, m_column_count, row, data)) {
+		else if (m_column_count <= line_last_column) {

I think the condition is correctly transcribed from is_selected callback to checking the range, but possibly the condition itself wasn't correct?

When I change m_column_count-1 to G_MAXLONG in get_text_displayed_a11y the crash goes away.

Should this API accept -1 to mean 'end of line' as opposed to current which is 'end of last line' (ie nothing on this line) ?
Comment 3 Egmont Koblinger 2015-12-11 20:50:39 UTC
I'm not following your c++ refactoring, so I'd just let you do whatever you prefer and fixes this :)
Comment 4 Christian Persch 2015-12-15 19:41:00 UTC
Fixed on master. The assert in a11y may need to be removed/fixed too, since it appears it can trigger in other conditions too. But we have bug 758678 for that, so closing this one.