Bug 1547 - Watch unusable when evaluation large strings, Monodevelop gets stuck or crashes
Summary: Watch unusable when evaluation large strings, Monodevelop gets stuck or crashes
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: 2.8
Hardware: Macintosh Mac OS
: High normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-10-18 07:22 UTC by René Ruppert
Modified: 2012-01-31 19:16 UTC (History)
5 users (show)

Tags: gtk
Is this bug a regression?: ---
Last known good build:


Attachments
Attachment showing character garbage (37.52 KB, image/png)
2011-10-18 07:22 UTC, René Ruppert
Details
does the same thing in the visualizer dialog (34.80 KB, image/png)
2011-11-18 15:20 UTC, Jeffrey Stedfast
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED FIXED

Description René Ruppert 2011-10-18 07:22:02 UTC
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.
Comment 1 Jeffrey Stedfast 2011-11-18 15:20:55 UTC
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...
Comment 2 Jeffrey Stedfast 2011-11-18 16:03:16 UTC
It seems that somewhere around 586696 characters causes the overlapping text wrapping behavior in both the GtkCellRendererText and also GtkTextView.
Comment 3 Jeffrey Stedfast 2011-12-01 16:11:44 UTC
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.
Comment 4 Jeffrey Stedfast 2011-12-01 16:26:36 UTC
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).
Comment 5 Jeffrey Stedfast 2011-12-02 15:20:15 UTC
Okay, we just need the gtk fixes now...
Comment 6 Jeffrey Stedfast 2011-12-14 13:36:13 UTC
Just submitted a bug upstream to gtk: https://bugzilla.gnome.org/show_bug.cgi?id=666193
Comment 7 Michael Natterer 2012-01-26 08:34:40 UTC
Pango measurement overflows for such large strings. I commented
in upstream bugzilla and started discussing the issue in #gtk+ on IRC.
Comment 8 Michael Natterer 2012-01-26 10:37:36 UTC
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 ;)
Comment 9 Kristian Rietveld (inactive) 2012-01-28 05:48:48 UTC
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).
Comment 10 Jeffrey Stedfast 2012-01-31 19:16:42 UTC
Implemented the last bit in git master, which was chunking raw strings over the wire.