2010-10-16 11 views
7

Ho un sito Web che improvvisamente ha iniziato a bloccare Internet Explorer.Il mio sito Web continua a bloccarsi IE, impossibile eseguire il debug

Il sito Web carica e avvia l'esecuzione di javascript ma da qualche parte la macchina esplode. Non ho nemmeno un errore di script, si blocca solo. Ho provato a scorrere manualmente ogni singola riga di js con il debugger integrato, ma ovviamente il problema non si verifica.

Se scelgo di eseguire il debug dell'applicazione quando si blocca, viene visualizzato il seguente messaggio.

Eccezione non gestita a 0x6c5dedf5 in iexplore.exe: 0xC0000005: posizione di lettura di violazione di accesso 0x00000090.

I primi 5 articoli in stack di chiamate assomiglia a questo

Vgx.dll! 6c5dedf5()
[Fotogrammi di seguito potrebbero essere errati e/o mancante, senza simboli caricati per Vgx.dll]
Vgx.dll! 6c594d70()
Vgx.dll! 6c594f63()
Vgx.dll! 6c595350()
Vgx.dll! 6c58f5e3()
mshtml.dll! 6f88dd17()

VGX.dll sembra essere parte del renderer di vml e in effetti utilizzo VML. Non sono sorpreso perché ho avuto così tanti problemi con vml, gli attributi devono essere impostati in ordine specifico, a volte non puoi impostare attributi quando hai elementi collegati alla dom o viceversa (tutto non documentato btw) ma poi i problemi di solito può essere riprodotto in fase di debug, ma non ora :(

Il problema si verifica anche in nessun plug-mode

v'è un approccio migliore rispetto tentativi ed errori per risolvere questo

Edit:.? L'aggiunta di una console che emette ogni modifica sospetta al DOM ha fatto si che il problema si verifichi solo occasionalmente (la console è anche implementato in javascript nella stessa pagina, sono in grado di vedere l'output anche dopo un crash in quanto la finestra è ancora visibile) Apparentemente sembra essere una sorta di condizione di gara.

Sono riuscito a rintracciarlo ulteriormente e sembra che si verifichi quando si rimuove un oggetto dal DOM troppo rapidamente dopo che è stato appena aggiunto. (molto probabilmente solo per gli elementi vml con qualche attributo speciale, non ho provato ulteriormente) E non può essere risolto aggiungendo un ciclo morto davanti a removeChild (soluzione piuttosto cattiva comunque), la pagina deve essere resa dal browser una volta dopo l'addChild prima di poter chiamare removeChild. sospiro

+1

Sto scherzando - ma, beh, si potrebbe essere in grado di forgiare un (altro) exploit per IE da questo. Voglio dire, finisci per leggere da qualche parte di memoria. Forse puoi farti fare qualcosa di veramente brutto. Inoltre, un windows/IE completamente aggiornato e aggiornato non dovrebbe bloccarsi da nessun sito Web, indipendentemente da quanto errato sia il codice. Forse c'è un posto dove segnalarlo? – zerm

+1

Inviami una pagina di ripro o URL; Sono felice di dare un'occhiata! (ericlaw @ microsoft). Grazie! – EricLaw

+0

FYI, la prossima volta impostare il server dei simboli sul server dei simboli Microsoft per ottenere uno stack di chiamate migliore: http://msdn.microsoft.com/en-us/library/b8ttk8zy%28v=vs.80%29.aspx –

risposta

1

Interrompere l'utilizzo di VML?

Se hai bisogno di cose in IE che davvero non possono essere fatte spostando, ridimensionando, ritagliando e sostituendo le immagini, prendi in considerazione l'uso di Flash, Silverlight o simili.

Se la tua vita dipende da VML, leggi il più possibile sull'esperienza di altre persone, che potrebbe facilitare l'approccio per tentativi ed errori.

0

Assicurarsi che gli script siano in esecuzione dopo l'evento DOMReady. IE è noto per il crash quando si modifica il DOM prima che sia completamente caricato.

In alcuni casi, IE potrebbe attivare prematuramente l'evento DOMReady. Vedi ulteriori informazioni su come superare questo here e here.

+0

Don Penso che sia per questo perché il problema può verificarsi molto tempo dopo il caricamento della pagina e l'interazione dell'utente. Cercherò di verificarlo di più anche se il mio inizializzatore onload è un po 'un hack in questo momento. –

0

Stai utilizzando JSONP in qualsiasi forma? Implementazioni popolari come jQuery tendono a cercare di ripulire la memoria eliminando il nodo script dal DOM dopo che è stato eseguito. Ho visto questo crash di Internet Explorer in molti casi. Non sono mai riuscito a capire quali altre condizioni dovessero essere in giro per causare l'arresto. Troppe cose che succedono nelle mie altre pagine.

Ad ogni modo, se si sta utilizzando jQuery.getJSON, controllare la seguente riga nel fonte jQuery: (linea 5556 su jQuery 1.4.3):

} else { 
    // Garbage collect 
    window[ jsonp ] = undefined; 

    try { 
    delete window[ jsonp ]; 
    } catch(jsonpError) {} 
} 

if (head) { 
    head.removeChild(script); 
} 

È possibile rimuovere con sicurezza che, o condizionare lo solo nei browser non IE. Speriamo che questo aiuti.

+0

No, non usare affatto JSONP o jQuery. –

4

(domanda vecchio ma importante)

ho avuto un problema molto simile - tra cui un sacco di VML complesso (da Raffaello), e sembrava quasi impossibile eseguire il debug.

In realtà, si è scoperto che il più semplice approccio low-tech era il migliore. È un approccio ovvio: sto scrivendo qui perché a volte, di fronte a un problema intimidatorio, le soluzioni ovvie e semplici sono l'ultima a cui una persona pensa.

Così, semplice debug della vecchia scuola: Un sacco di alert("1");, alert("2"); ecc prima e dopo ogni esigente in remoto o chiamata complesso nel mio codice, dando super-semplici punti di interruzione affidabili che non si basano su tutte le funzioni (ad esempio strumenti di sviluppo) che potrebbero precipitare fuori. Quindi, basta vedere quale numero di avviso si arriva prima che si blocchi: il problema deve sorgere tra quell'avviso e il successivo.

Aggiungi altri avvisi fino a quando non lo si restringe fino alla linea esatta. Nel mio caso, in realtà non aveva nulla a che fare con il VML complesso: era un ciclo continuo che, per qualche motivo, continuava all'infinito solo su IE7.

+0

Sì. Siamo accecati dai nostri fantasiosi strumenti, eppure molto spesso le vecchie tecniche funzionano meglio. –

1

E 'un puntatore nullo dereferenziamento incidente non sfruttabile