Come può un glfwSleep () causare un segfault?

StackOverflow https://stackoverflow.com/questions/902687

Domanda

nella mia applicazione multithraded, sto usando una funzione sleep () (quello dalla libreria GLFW): 

glfwSleep(..);

e conduce a quanto pare la mia domanda per andare in segfault come il mio stack di chiamate mostra: 

#0 76CFC2BC WaitForSingleObjectEx() (C:\Windows\system32\kernel32.dll:??)
#1 00000016 ??() (??:??)
#2 0000006C ??() (??:??)
#3 00000000 ??() (??:??)

Il glfwSleep() viene usata all'interno di un filo. Che è pericoloso? Perché il mio programma di segfault in conseguenza a questo?

Modifica:

Quando il parametro del glfwSleep() è <0,02 (sec) non SEGFAULT!

Modifica 2:

Dalla documentazione ufficiale di GLFW:

  

scrittura threaded applicazioni possono essere   molto imbarazzante prima ci si abitua a   , ma ci sono alcune regole fondamentali che   sono abbastanza semplice da seguire:

     
      
  • SEMPRE assicurare l'accesso esclusivo ai dati che è condiviso tra i thread!
    •   
  • Assicurarsi che le discussioni siano sincronizzati correttamente!
    •   
  • attesa MAI occupato!
    •   

Credo che ho ottenuto il mio answer..have di trovare un'alternativa ora ..

Grazie!

È stato utile?

Soluzione

il GLFW wiki :

  

GLFW non funziona bene con GHC   fili, forkIO o threadDelay. Così   evitare, se è possibile.

Altri suggerimenti

È segfault'ed filo stesso thread del chiamante del glfwSleep ()?

sembra che l'incidente causato dalla chiamata di WaitForMultipleObjectsEx API. non si specifica e passare agli oggetti di sincronizzazione corrette e numeri per WaitForMultipleObjectsEx?

Per citare The Pragmatic Programmer ,

  

`` selezionare’’ non è rotto

     

E 'raro   trovare un bug nel sistema operativo o il compilatore,   o anche un prodotto di terze parti o   biblioteca. Il bug è più probabile nel   applicazione.

Perché è il vostro programma chiamante WaitForSingleObjectEx() quando glfwSleep() chiama Sleep()? Beh, anche se non si dispone il codice sorgente per Sleep(), non è del tutto una scatola nera. Smontare Sleep() e probabilmente vedrete (a seconda della versione di Windows in uso) che Sleep() sia chiamate o coda chiamate SleepEx(). Su XP, SleepEx() chiama NtDelayExecutionThread(), e su Vista chiama WaitForSingleObjectEx().

Quindi, cosa è successo al resto del tuo stack? 00000016, 0000006C, e 00000000 non sono validi gli indirizzi di ritorno. Non sarei sorpreso se da qualche parte nel codice, si passa un puntatore a un buffer di stack-assegnato a un altro thread, e mentre il programma sta dormendo, che altro thread corrompe lo stack prima del thread. Passo in Sleep(), mettere un punto di interruzione memoria l'indirizzo di ritorno, e si può essere in grado di catturare il colpevole.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top