Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 716 [details]
Attachment showing character garbage
It happens that my client-server app is confronted with long strings (1 Megabyte in size) in error situations.
If I try to debug and hover one of the strings, I can see garbage: the strings seems to get wrapped and characters overlap. Same is true for the watch or for the immediate window. See screenshot.
In addition it takes Monodevelop about 3 minutes to show the string on my Mac Mini. If I manage to bring up the value visualizer, the string is shown correctly.
Every subsequent action like selecting text in the visualizer takes forever.
I think some performance optimization is required here or at least truncation of the string when not using the visualizer.
Created attachment 909 [details]
does the same thing in the visualizer dialog
Might be a gtk bug? I don't see what we are doing that could *possibly* cause this issue since we just pass the string to gtk to render.
The slowness is definitely gtk, but that's kinda to be expected to render a 1 MB string.
Also, this happens in the Visualizer too, not just the cell renderer which makes me think it is a gtk bug even more...
It seems that somewhere around 586696 characters causes the overlapping text wrapping behavior in both the GtkCellRendererText and also GtkTextView.
So there are several issues here:
1. the Gtk/Pango text wrapping bug
2. we need to discuss changing the protocol for the soft debugger to allow sending values over the wire in smaller chunks (so that we can just fetch a small amount of data for tooltip and other summary displays, and then fetch the rest of the chunks in a cancelable way for the Visualizer dialog)
3. fix the logic that displays this info in tooltips and other places to truncate/ellipsize them
We'll need the Lanedo guys to fix the Gtk/Pango bug, but we'll need to fix the other parts.
I'm splitting this into the 3 bugs I listed above.
We'll pass this one along to Lanedo (e.g. this will become the canonical bug for #1)
I've just filed bug #2301 for #2
I've also filed bug #2302 to handle truncation of the values shown in the tooltips (which is the one I'm going to focus on fixing for now).
Okay, we just need the gtk fixes now...
Just submitted a bug upstream to gtk: https://bugzilla.gnome.org/show_bug.cgi?id=666193
Pango measurement overflows for such large strings. I commented
in upstream bugzilla and started discussing the issue in #gtk+ on IRC.
I attached a patch to the upstream bug that adds a max-length property
to GtkCellRendererText which, if set, avoids both the overflows in Pango
and the performance issues.
You are free to choose if this is an elegant fix of two issues at the
same way, or simply an evil way to avoid a real fix ;)
I posted some comments on the upstream bug. Basically, I think it is worthwhile to check if the problem exists on Linux (which given Mitch' analysis is likely) and then think about patching GtkEntry/GtkCellRendererText/GtkTextView to render things in chunks (which is probably not trivial).
Implemented the last bit in git master, which was chunking raw strings over the wire.