Visual Studio 2013 C++ - Überwachungsfenster: Arrays werden falsch in die Zwischenablage kopiert

Question

Ich habe diese Frage jetzt direkt mit Microsoft here, here und here aufgeworfen. Offensichtlich tritt das Problem immer noch in der aktuellen RC für VS2015 auf (siehe zweiten Link oben).

In Visual Studio 2013 ist es möglich, mehrere Elemente eines C-Arrays mit einem Watch wie p, 10000 anzuzeigen (wobei p beispielsweise ein Double * ist).

Im folgenden Beispiel zeige ich einen Screenshot eines Teils eines solchen Arrays im Watch-Fenster und den gleichen Teil des Arrays wie CTRL-C kopiert und CTRL-V in einen Texteditor eingefügt. Beachten Sie, dass die kopierten/eingefügten Werte ab Element 25 nicht mehr mit denen im Überwachungsfenster übereinstimmen (die korrekt sind).

[20] 1.0945579725021715 double 
    [21] 0.99979213435791758 double 
    [22] 1.0971002689671798 double 
    [23] 0.99977802981060826 double 
    [24] 1.1002739126009620 double 
    [25] 0.99964664435140704 double 
    [26] 1.1054689877466559 double 
    [27] 0.99963245464284955 double 
    [28] 1.1002149405804762 double 
    [29] 0.99961125488418856 double 
    [30] 1.0956742333763470 double 

Bisher in meinen Experimenten Ich neige dazu, zu sehen sind die ersten Werte und die letzten Werte kopiert einen mittleren Abschnitt des Arrays korrekt zu verlassen, die nicht korrekt ist. Es geht nicht immer schief. Oft funktioniert es für das erste geprüfte Array, für die nachfolgenden jedoch falsch. Auch wenn es schief geht, scheint es, dass das Kopieren/Einfügen der Werte ein zweites Mal manchmal zu einem korrekten Ergebnis führt. Es scheint, dass die falschen Zahlen in der Regel die vorherigen Werte einiger Elemente des Arrays sind. Was in die Zwischenablage kopiert wird, ist eine Mischung aus dem aktuellen und dem vorherigen Inhalt des Arrays. Die Arrays, mit denen ich das sehe, sind 2000 plus Elemente lang.

Dies deutet auf eine fälschlicherweise ungültige (d. H. Manchmal nur teilweise aktualisierte) Kopie der Daten hin, die bei der Implementierung des Kopierens in die Zwischenablage von Visual Studio verwendet werden. Meine Experimente legen nahe, dass Elemente in der Kopie der in die Zwischenablage gerenderten Daten genau dann aktualisiert werden, wenn diese Elemente (oder ausreichend "nahegelegene" Elemente - es könnte eine "Paging Block Size" involviert sein) auf dem Bildschirm angezeigt wurden . Insbesondere beim Scrollen durch das Array scheint eine Seite nach der anderen zu bewirken, dass das Kopieren korrekt funktioniert, während das Blättern von oben nach unten mit den Tasten HOME und END nicht dazu führt, dass der mittlere Abschnitt des Arrays aktualisiert wird die Kopie, die dann in die Zwischenablage gerendert wird.

In der Tat, wenn man mehrere Uhren auf dem gleichen Array einrichtet, kann man mehrere Antworten erhalten, zum Beispiel werden die Daten in die Zwischenablage kopiert, nachdem sie dreimal auf denselben Haltepunkt geklickt haben. Wenn der Breakpoint das erste Mal getroffen wird, kopiere ich alle Daten und alles wird korrekt in die Zwischenablage kopiert. Das zweite Mal ist lückenhaft. Wichtigerweise habe ich dann ungefähr 25% des Weges durch das Beobachtungsfenster gescrollt, genug um die gelben Daten in die Zwischenablage zu injizieren. Ich kehrte dann zum Beginn des Überwachungsfensters zurück und setzte die Ausführung fort, bis der Haltepunkt das dritte Mal getroffen wurde. Ich habe dann alle Daten im Überwachungsfenster ausgewählt und mit STRG-A STRG-C kopiert. Das Ergebnis ist, dass die Daten in pink von dem ersten Mal stammen, an dem der Haltepunkt getroffen wurde. Die Daten in Gelb stammen vom zweiten Mal und die nicht hervorgehobenen Daten sind tatsächlich korrekt. Beachten Sie, dass die Elemente 0 und 1 der pinkfarbenen Daten nicht mehr mit der Zusammenfassung des Arrays über ihnen übereinstimmen! Ich habe die Elemente 2-497 und 503-997 der Kürze halber weggelassen.

Ich habe gesehen, ein solches Verhalten nicht zuvor verschiedene VC++ Versionen von 6 ab Nachdem verwendet und nicht sofort in der Lage gewesen, einen Verweis auf sie im Web zu finden.

Wenn man sich beim Debuggen von etwas Komplexem auf diese Funktionalität verlässt, kann man sich den Kopf kratzen und sich über die seltsamen Zahlen lange wundern, bevor man realisiert, dass man irregeleitet wird.

Ich bin mit Microsoft Visual Studio Professional 2013, Version 12.0.31101.00 Update 4

Hat jemand gesehen und jemand mehr weiß über sie oder wissen, ob ein Update oder Abhilfe für sie?

Answer 1

Verschiedene Kollegen sehen das auch. Offensichtlich betrifft es auch Visual Studio 2015-Editionen.

Während ich schreibe, haben Microsoft anscheinend den Fehlerbericht akzeptiert und das Problem repliziert, aber noch keinen Zeitplan oder Plan für eine Reparatur angegeben.

Eine Problemumgehung besteht darin, alle Daten im Überwachungsfenster durchzublättern, die vor dem Kopieren kopiert werden sollen. Scheinbar wird das, was gezeigt wird, aktualisiert, aber was nicht gezeigt wurde, ist nicht unbedingt aktuell an dem Punkt, an dem die Daten kopiert werden.

-Update (Feb 2018)

Die einfache Repro unten jetzt korrekt in Visual Studio arbeitet 2017. So sieht es aus wie der Fehler behoben ist, wenn auch die Kopie der Bühne Fenster erscheinen Äonen und ein Pop-up nimmt während 10000 Textzeilen werden in der Zwischenablage erstellt. Es war viel schneller (und funktionierte korrekt) bis einschließlich Visual Studio 2010.

Haben Sie eine Uhr auf a und erweitern Sie es. Strg-A, Strg-C bedeutet, dass alles im Überwachungsfenster ausgewählt und kopiert wird.

int a[10000]; 
for (int i=0; i<10000; ++i) 
    a[i] = i; 

(void)a[0]; // breakpoint here, Ctrl-A, Ctrl-C, paste somewhere 

for (int i=0; i<10000; ++i) 
    a[i] += 100; 

(void)a[0]; // breakpoint here, Ctrl-A, Ctrl-C, paste somewhere 

Visual Studio 2013 und 2015 geben Ihnen so etwas wie dieses

-  a 0x00ef5af4 {100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, ...} int[10000] 
     [0] 100 int 
     [1] 101 int 
     [2] 102 int 
     [3] 103 int 
     [4] 104 int 
     [5] 105 int 
     [6] 106 int 
     [7] 107 int 
     [8] 108 int 
     [9] 109 int 
     [10] 110 int 
     [11] 11 int // Oops. The line it goes wrong on depends 
     [12] 12 int // on the number of visible lines in the 
     [13] 13 int // watch window. 
...