Hi Axel,
First of all thank you for your hints, I've spent several hours trying to address this, actually I was able to produce a dump using stackshot, unfortunately I'm not able to resolve the symbols of the running kernel, I've tried several methods, after downloading the 10.6.7 symbols, with no success
This is the dump of one thread stuck into the close() system call, does anybody here is able to resolve the kernel stack to a function call that make sense ?
Thanks a lot !
Kernel stack:
0xffffff800022c888 (0xffffff800022c888)
0xffffff800020990e (0xffffff800020990e)
0xffffff8000209acb (0xffffff8000209acb)
0xffffff8000206270 (0xffffff8000206270)
0xffffff800024e416 (0xffffff800024e416)
0xffffff800024e865 (0xffffff800024e865)
0xffffff800047238c (0xffffff800047238c)
0xffffff80004741ff (0xffffff80004741ff)
0xffffff80004742f6 (0xffffff80004742f6)
0xffffff80004e8158 (0xffffff80004e8158)
0xffffff80002e4874 (0xffffff80002e4874)
User stack:
close (in libSystem.B.dylib) + 10 (0x7fff875ce99a)
MFramework::MSocket::CMSocketStream::Close() (in libVVFramework.dylib) (VVSocket.cpp:459) (0x1004c18a5)
MDispatcher::IMDispClientsLogic::SocketEventClose(MFramework::MSocket::CMSocketStream*, bool) (in libVVDispatcherCore.dylib) (IDisp_ClientLogic.cpp:3296) (0x1000e58bc)
MDispatcher::IMDispClientsLogic::clientsHandlingThread(void*) (in libVVDispatcherCore.dylib) (IDisp_ClientLogic.cpp:3634) (0x1000fb777)
_pthread_start (in libSystem.B.dylib) + 331 (0x7fff875fd4f6)
thread_start (in libSystem.B.dylib) + 13 (0x7fff875fd3a9)
>> Hello Leonardo, Since you didn't provide many details, perhaps could this thread prove somewhat enlightening: http://lists.apple.com/archives/darwin-kernel/2010/Aug/msg00022.html
(be sure to read the whole thread, as its subject has changed in the middle)
HTH,
Axel
>> Hi all, I would like to thanks anyone who can help me with this matter because I'm stuck since several days finding a solution.I've converted a multithreaded tcp server that acts on sockets to a kqueue/kevent based design.I've read several things online, someone states that kqueue is multithreaded supported in darwin (invoking kqueue/kevents from multiple threads listening for events on the same kqueue descriptor as well as send kevents requests from different threads), while someone says that kqueue is not multithreaded supported.My issue happens ONLY when I need to close an FD registered in kqueue in response to a EV_EOF event, basically I end with the kernel stuck on the close() function and when I experience this, I'm even unable to kill the process using KILL -9 , sudo kill -9 or whatever else, the only solution is to reboot the machine. I've read somewhere that this may be a race condition at the kernel level, but I was not able to discover the root cause of this using gdb, I've also tried to lower my serving threads to a number of 1 , and I still experience this issue (maybe because of other threads in the software logic that sends kevent requests...I don't know at this point). Is there someone here that may explain me the design limits of kqueue as well as a way to troubleshoots this lock condition on the close() kernel function ? thanks a lot ! Leonardo Bernardini
|