Comment un glfwSleep () provoquer une erreur de segmentation?

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

Question

dans ma demande multithraded, j'utilise une fonction sleep () (celui de la bibliothèque GLFW): 

glfwSleep(..);

et il conduit apparemment à ma demande segfaulting que ma pile d'appel indique: 

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

Le glfwSleep() est utilisé à l'intérieur d'un fil. Est-ce dangereux? Pourquoi mon programme segfaulting en conséquence à cela?

Edit:

Lorsque le paramètre de la glfwSleep() est <0,02 (secs) ne pas segmentation fault!

Edit 2:

De la documentation officielle de GLFW:

  

applications multithreads d'écriture peuvent être   très difficile avant de vous habituer à   , mais il y a quelques règles clés   sont assez simples à suivre:

     
      
  • TOUJOURS assurer un accès exclusif aux données partagées entre les threads!
    •   
  • Assurez-vous que les fils sont synchronisés correctement!
    •   
  • jamais occupé attendre!
    •   

Je pense que je suis mon answer..have de trouver une alternative maintenant ..

Merci!

Était-ce utile?

La solution

De le wiki GLFW :

  

GLFW ne fonctionne pas bien avec GHC   fils, forkIO ou threadDelay. Alors   les éviter si vous le pouvez.

Autres conseils

est-fil segfault'ed même fil de l'appelant du glfwSleep ()?

il semble que l'accident causé par l'appel de l'API WaitForMultipleObjectsEx. ne vous précise et passez aux objets de synchronisation et de chiffres corrects à WaitForMultipleObjectsEx?

Le Pragmatic Programmer ,

  

`` select » » est pas cassé

     

Il est rare de   trouver un bogue dans le système d'exploitation ou le compilateur,   ou même un produit tiers ou   bibliothèque. Le bug est plus probable dans le   application.

Pourquoi votre programme WaitForSingleObjectEx() quand glfwSleep() appellent les appels Sleep()? Eh bien, même si vous ne disposez pas du code source à Sleep(), ce n'est pas complètement une boîte noire. Démontez Sleep() et vous verrez probablement (selon la version de Windows que vous avez) que Sleep() soit des appels ou queue appels SleepEx(). Sur XP, SleepEx() appelle NtDelayExecutionThread(), et Vista appelle WaitForSingleObjectEx().

Qu'est-il arrivé au reste de votre pile? 00000016, 0000006C et 00000000 ne sont pas des adresses de retour valides. Je ne serais pas surpris si quelque part dans votre code, vous passez un pointeur vers une mémoire tampon allouée pile à un autre thread, et pendant que votre programme dort, l'autre fil corrompt la pile du premier fil. Entrez dans Sleep(), mettez un point d'arrêt de mémoire sur l'adresse de retour, et vous pourrez peut-être attraper le coupable.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top