GNOME Bugzilla – Bug 660462
Vte.Terminal.set_colors() does not work properly
Last modified: 2013-04-14 11:06:58 UTC
Created attachment 197761 [details] Screenshot of the problem llo, I'm using VTE with Python, and I have an issue with the Vte.Terminal.set_colors() function. This function works for setting the foreground and the background colors, but not for the palette. Instead of using the colors sets in the palette, I obtain various blue colors (it is not the same blue at every run...). I attach a screen shot of the problem, and a small python code for reproducing the bug. Regards,
Created attachment 197762 [details] Small Python code for reproducing the bug
> (it is not the same blue at every run...). That would indicate some uninitialised / invalid memory read going on; can you valgrind your testcase with latest vte-0-32 branch and check if it turns up anything in the valgrind log? See https://live.gnome.org/Valgrind (also use the --track-origins=yes switch).
Created attachment 209435 [details] Valgrind log for the testcase (In reply to comment #2) > That would indicate some uninitialised / invalid memory read going on; can you > valgrind your testcase with latest vte-0-32 branch and check if it turns up > anything in the valgrind log? See https://live.gnome.org/Valgrind (also use the > --track-origins=yes switch). I decided to try this and ran $ G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck --leak-check=full --leak-resolution=high --num-callers=20 --log-file=vgdump --track-origins=yes /usr/bin/python2 testcase.py The output was pretty large (see attachment) and I don't know what to look for, but it complains about invalid reads, uninitialised values and possibly lost blocks... The summary says: ==21375== LEAK SUMMARY: ==21375== definitely lost: 0 bytes in 0 blocks ==21375== indirectly lost: 0 bytes in 0 blocks ==21375== possibly lost: 847,948 bytes in 409 blocks ==21375== still reachable: 5,536,194 bytes in 8,203 blocks ==21375== suppressed: 0 bytes in 0 blocks ==21375== Reachable blocks (those to which a pointer was found) are not shown. ==21375== To see them, rerun with: --leak-check=full --show-reachable=yes ==21375== ==21375== For counts of detected and suppressed errors, rerun with: -v ==21375== ERROR SUMMARY: 11799 errors from 506 contexts (suppressed: 2 from 2)
So this was with vte from vte-0-32 branch, plus latest pygobject ? And it was still reproducible? There is lots and lots of bad stuff from python, but no vte symbols show up on the invalid reads...
You could also try to run under gdb, set a breakpoint on vte_terminal_set_colors and print the stack and the arguments to see if it's python inputting bogus values to vte.
Yes, it's reproducible with vte-0-32 and pygobject 3.0.3. I could try gdb, but I've never used it before and I'm not sure when I will have the time to learn how to.
I think this is a pygobject issue. I debugged a bit inside the vte_terminal_set_colors function and it gets a correctly allocated palette, also the palette size is set correctly. However, the actual GdkColor values seem to be garbaged (the red and green components are always zero, and the blue component varies from run to run). I tried to look a bit at the gdb stacktrace but I'm not sure it's very useful as I don't have debug symbols for some libraries (python and girepository).
-> pygobject
This seems to be related to bug #664848. As far as I understand, GdkColor is a boxed type. The gir cannot encode whether an array is passed as a GdkColor ** or a GdkColor * (terminology being non-flat and flat) and heuristics decide that for boxed type, they should be passed non-flat.
Created attachment 241490 [details] Updated example for Python3 and latest PyGObject
The API has changed a bit since this was logged. I've attached an updated example which now works.