How can a glfwSleep() cause a segfault?

Question

in my multithraded application, I'm using a sleep() function (the one from the GLFW library):

glfwSleep(..);

and it apparently leads my application to segfaulting as my call stack shows:

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

The glfwSleep() is used inside a thread. Is that dangerous? Why is my program segfaulting as a consequence to that?

Edit:

When the parameter of the glfwSleep() is < 0.02 (secs) it doesn't segfault!

Edit 2:

From the official documentation of GLFW :

Writing threaded applications may be very awkward before you get used to it, but there are a few key rules that are fairly simple to follow:

• ALWAYS assure exclusive access to data that is shared between threads!
• Make sure that threads are synchronized properly!
• NEVER busy wait!

I think i got my answer..have to find an alternative now..

Thanks!

Answer 1

From the GLFW wiki:

GLFW doesn't work well with GHC threads, forkIO or threadDelay. So avoid them if you can.

Answer 2

Is segfault'ed thread same thread of caller of the glfwSleep()?

it seems that the crash caused by the call of WaitForMultipleObjectsEx API. does you specifies and pass to the correct sync objects and numbers to WaitForMultipleObjectsEx?

Answer 3

To quote The Pragmatic Programmer,

``select’’ Isn’t Broken

It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

Why is your program calling WaitForSingleObjectEx() when glfwSleep() calls Sleep()? Well, even though you don't have the source code to Sleep(), it's not completely a black box. Disassemble Sleep() and you'll probably see (depending on which version of Windows you have) that Sleep() either calls or tail-calls SleepEx(). On XP, SleepEx() calls NtDelayExecutionThread(), and on Vista it calls WaitForSingleObjectEx().

So what happened to the rest of your stack? 00000016, 0000006C, and 00000000 aren't valid return addresses. I would not be surprised if somewhere in your code, you pass a pointer to a stack-allocated buffer to another thread, and while your program is sleeping, that other thread corrupts the first thread's stack. Step into Sleep(), put a memory breakpoint on the return address, and you may be able to catch the culprit.