GNOME Bugzilla – Bug 728051
segv in vte_terminal_get_rgb_from_index
Last modified: 2014-04-26 15:36:54 UTC
From https://bugzilla.redhat.com/show_bug.cgi?id=1084652 [https://retrace.fedoraproject.org/faf/reports/394777/]:
+ Trace 233465
Thread 1 (Thread 0x7fb92ff9fac0 (LWP 4623))
Looks vte_terminal_get_color returned NULL here. I noticed that there are more places in our code where the return value isn't checked and the colour from the out value used nevertheless.
s/and the colour from the out value used nevertheless//
What should happen: Three special colors (cursor bg, highlight bg/fg) can be unset, so it's okay for vte_terminal_get_color to return NULL on these, but only on these. It should be okay to omit the null-check if the index is not one of these special ones. The init code should set the palette accordingly, and the API shouldn't allow to unset any color except those three special ones. A character cell should never have any of these special colors. The current crash occurs in vte_terminal_get_text_range_maybe_wrapped() where we call vte_terminal_get_rgb_from_index() on pcell->attr.fore/back which should correspond to a physical cell. My first (and currently only) theory on what's going wrong: The palette is initialized when the widget is realized, not when initialized. Is it possible that VteTerminal is initialized but not yet realized, and then someone calls vte_terminal_get_rgb_from_index()?
Created attachment 274136 [details] [review] maybe fix?
Created attachment 274138 [details] [review] maybe fix? v2 If the previous patch works, here's one with further cleanup (some code simplification and comment fixes).
Comment on attachment 274138 [details] [review] maybe fix? v2 "Maybe fix" submitted. Let's watch downstream bug to see if it fixes the issue.
I tested the patch on openSUSE 13.1 with GNOME 3.12 and it fixes the qemu crash for me. Thanks!
İsmail, thanks a lot for your feedback, it's great to hear it :) ChPe, given the severity, could you please do a vte-0.36.1 release?