2015-06-11 19 views
7

Ora ho sollevato questa domanda direttamente con Microsoft here, here e here. Apparentemente il problema si pone ancora nell'attuale RC per VS2015 (vedi il secondo link sopra).Finestra di controllo Visual Studio 2013 C++: le matrici vengono copiate in modo errato negli appunti

In Visual Studio 2013 è possibile visualizzare più elementi di un array C utilizzando un orologio come p, 10000 (dove p è un doppio * per esempio).

Nell'esempio seguente, viene mostrato uno screenshot di una parte di tale array come visualizzato nella finestra di controllo e la stessa parte dell'array come CTRL-C copiato e CTRL-V incollato in un editor di testo. Nota che dall'elemento 25 in poi i valori copia/incollati non sono in linea con quelli nella finestra di controllo (che sono corretti).

Watch window

[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 

Finora nei miei esperimenti tendo a vedere i primi valori e gli ultimi valori pochi vengono copiati correttamente lasciando una sezione centrale della matrice che non è corretto. Non sempre va storto. Spesso funziona per la prima matrice ispezionata ma va male per quelli successivi. Inoltre, quando va male sembra che copiare/incollare i valori una seconda volta a volte porti a un risultato corretto. Sembra che i numeri errati siano generalmente i valori precedenti di alcuni elementi dell'array - ciò che viene copiato negli appunti è una combinazione dei contenuti attuali e precedenti dell'array. Gli array con cui vedo questo sono più di 2000 elementi.

Questo è un suggerimento di una copia erroneamente invalidata (vale a dire solo parzialmente aggiornata) dei dati utilizzati nell'implementazione di Visual Studio della copia negli appunti. I miei esperimenti suggeriscono fortemente che gli elementi nella copia dei dati renderizzati negli appunti vengono aggiornati se e solo se quegli elementi (o elementi sufficientemente "vicini" - sembra che ci potrebbe essere una "dimensione del blocco di paging" coinvolto), sono stati mostrati sullo schermo . In particolare, scorrere la matrice di una pagina alla volta sembra far sì che la copia funzioni correttamente mentre il flicking dalla parte superiore dell'array alla parte inferiore di essa usando i tasti HOME e END non porta alla sezione centrale dell'array che viene aggiornata in la copia che viene poi resa negli appunti.

Infatti, se uno imposta più orologi sullo stesso array, è possibile ottenere più risposte, ad esempio questo è il dato copiato negli appunti dopo aver colpito lo stesso punto di interruzione tre volte. La prima volta che viene colpito il punto di interruzione, copio tutti i dati e tutto viene copiato correttamente negli Appunti. La seconda volta è irregolare. Fondamentalmente ho fatto scorrere verso il basso circa il 25% del modo attraverso la finestra di controllo, abbastanza per iniettare i dati gialli in ciò che finisce negli appunti. Sono quindi tornato all'inizio della finestra di controllo e l'esecuzione è continuata fino alla terza volta che viene colpito il punto di interruzione. Ho quindi selezionato tutti i dati nella finestra di controllo e l'ho copiato utilizzando CTRL-A CTRL-C. Il risultato è che i dati in rosa sono la prima volta che viene colpito il punto di interruzione. I dati in giallo provengono dalla seconda volta e i dati non evidenziati sono corretti. Nota che gli elementi 0 e 1 dei dati rosa sono addirittura fuori linea con il riepilogo dell'array subito sopra di loro! Ho omesso gli elementi 2-497 e 503-997 per brevità.

Multiple watches

aver usato varie versioni VC++ dal 6 in poi non ho visto in precedenza un simile comportamento e non sono immediatamente stati in grado di trovare un riferimento ad esso sul web.

Se ci si basa su questa funzionalità quando si esegue il debug di qualcosa di complesso, si può grattarsi la testa chiedendosi degli strani numeri per anni prima di rendersi conto che uno è stato fuorviato.

Sto usando Microsoft Visual Studio Professional 2013, la versione di aggiornamento 12.0.31101.00 4.

Qualcun altro ha visto questo e qualcuno sa più su di esso o di sapere di una correzione o una soluzione alternativa per questo?

risposta

0

Anche vari colleghi lo vedono. Apparentemente influisce anche su Visual Studio 2015.

Mentre scrivo Microsoft ha apparentemente accettato la segnalazione di bug e ha replicato il problema ma non ha ancora indicato un calendario o un piano per una correzione.

Una soluzione alternativa consiste nello scorrere tutti i dati nella finestra di controllo che si desidera copiare prima di copiarli. Apparentemente ciò che viene mostrato viene aggiornato, ma ciò che non è stato mostrato non è necessariamente aggiornato nel momento in cui si copia i dati.

aggiornamento (Feb 2018)

La semplice Repro qui sotto ora funziona correttamente in Visual Studio 2017. Quindi sembra che il bug è stato risolto, anche se la fase di copia prende eoni e viene visualizzata una finestra pop-up durante 10000 righe di testo vengono create negli Appunti. Era molto più veloce (e funzionava correttamente) fino a quando non includeva Visual Studio 2010.

Avere un orologio su a ed espanderlo. Ctrl-A, Ctrl-C significa selezionare e copiare tutto nella finestra di controllo.

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 e il 2015 vi darà qualcosa di simile

-  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. 
...