November 2010 - Darwin-kernel

KDK lost again
by Godfrey van der Linden 18 Nov '10

18 Nov '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I can't find the KDK downloads anymore on the developer website. Neither Apple's search nor googles can even find it. Where can I get the 10.6.4 and 10.6.5 KDKs? Any help will be appreciated. Godfrey _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

(no subject)
by alex alex 11 Nov '10

11 Nov '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Importance: Normal _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Teardown race with socket filter
by Nick Blievers 11 Nov '10

11 Nov '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thanks for pointing that out. I can confirm I am seeing both of these issues (missing detaches, and sometimes missing unregister callbacks). On 10/11/2010, at 8:29 PM, Antoine Missout wrote: > Check my email from yesterday. > > http://lists.apple.com/archives/darwin-kernel/2010/Nov//msg00011.html > > I see the same leaks. > I've filed rdar:/8648013 > - Antoine > > > > On 2010-11-09, at 22:38, Nick Blievers wrote: > >> Hi, >> >> I have a socket filter which works most of the time, but I have noticed that sometimes the connections leak, ie, I never receive a sf_detach callback. The circumstance that causes this is when two threads race during the teardown. Specifically, a close() from userspace and a tcp_close() from an aio_worker thread. >> >> This is what the aio thread looks like: >> 0x31db3798 0x21b455 <panic+445> >> 0x31db37e8 0x21b54b <Assert+65> >> 0x31db3808 0x383de582 <com.trustdefender.kext.PacketFilter + 0x6582> >> 0x31db3a78 0x4c44dc <sflt_notify+92> >> 0x31db3aa8 0x4b1ac1 <soisdisconnected+49> >> 0x31db3ac8 0x355f63 <tcp_close+669> >> 0x31db3b08 0x3513dd <tcp_input+13323> >> 0x31db3cd8 0x3473f6 <ip_proto_dispatch_in+405> >> 0x31db3d18 0x348a95 <ip_input+5766> >> 0x31db3e48 0x348bbc <ip_proto_input+47> >> 0x31db3e68 0x32f121 <proto_input+144> >> 0x31db3ea8 0x31be3c <lo_input+25> >> 0x31db3ec8 0x317a3c <dlil_ifproto_input+117> >> 0x31db3ef8 0x31a1b4 <dlil_input_packet_list+698> >> 0x31db3f68 0x31a3f5 <dlil_input_thread_func+457> >> 0x31db3fc8 0x29e6cc <call_continuation+28> >> >> and this is the userspace thread (the exact stacktrace will change as the threads are racing, I don't usually manage to catch it but got lucky this time) >> >> 0x3794b988 0x226e57 <thread_invoke+1213> >> 0x3794ba08 0x2270f6 <thread_block_reason+331> >> 0x3794ba78 0x227184 <thread_block+33> >> 0x3794ba98 0x29d846 <lck_mtx_lock_wait_x86+330> >> 0x3794baf8 0x298328 <lck_mtx_lock+504> >> 0x3794bb08 0x383de363 <com.trustdefender.kext.PacketFilter + 0x6363> >> 0x3794bd78 0x4c44dc <sflt_notify+92> >> 0x3794bda8 0x4b1b3f <soisdisconnecting+48> >> 0x3794bdc8 0x358582 <tcp_disconnect+77> >> 0x3794bde8 0x358631 <tcp_usr_detach+59> >> 0x3794be08 0x4ad59e <soclose_locked+742> >> 0x3794be68 0x4ad646 <soclose+66> >> 0x3794be88 0x4696fc <fo_close+13> >> 0x3794bef8 0x46b4ad <close_internal_locked+302> >> 0x3794bf38 0x46b57e <close_nocancel+141> >> 0x3794bf78 0x4edaf8 <unix_syscall64+617> >> 0x3794bfc8 0x29f43d <lo64_unix_scall+77> >> >> Usually, the second thread is long gone, and the socket's so_filt has been cleared... but we are still in the sflt_notify() callback, and detach hasn't been called. Also, the socket itself has been put into the socket cache, so its finished its life cycle. >> >> This doesn't seem like anything to do with my code simply because my code shouldn't affect when callbacks happen!.... has anyone seen anything like this before? Got any suggestions? >> >> >> Thanks >> >> Nick _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/darwin-kernel/antoine.missout%40meta… >> >> This email sent to antoine.missout(a)metakine.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Teardown race with socket filter
by Nick Blievers 10 Nov '10

10 Nov '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi, I have a socket filter which works most of the time, but I have noticed that sometimes the connections leak, ie, I never receive a sf_detach callback. The circumstance that causes this is when two threads race during the teardown. Specifically, a close() from userspace and a tcp_close() from an aio_worker thread. This is what the aio thread looks like: 0x31db3798 0x21b455 <panic+445> 0x31db37e8 0x21b54b <Assert+65> 0x31db3808 0x383de582 <com.trustdefender.kext.PacketFilter + 0x6582> 0x31db3a78 0x4c44dc <sflt_notify+92> 0x31db3aa8 0x4b1ac1 <soisdisconnected+49> 0x31db3ac8 0x355f63 <tcp_close+669> 0x31db3b08 0x3513dd <tcp_input+13323> 0x31db3cd8 0x3473f6 <ip_proto_dispatch_in+405> 0x31db3d18 0x348a95 <ip_input+5766> 0x31db3e48 0x348bbc <ip_proto_input+47> 0x31db3e68 0x32f121 <proto_input+144> 0x31db3ea8 0x31be3c <lo_input+25> 0x31db3ec8 0x317a3c <dlil_ifproto_input+117> 0x31db3ef8 0x31a1b4 <dlil_input_packet_list+698> 0x31db3f68 0x31a3f5 <dlil_input_thread_func+457> 0x31db3fc8 0x29e6cc <call_continuation+28> and this is the userspace thread (the exact stacktrace will change as the threads are racing, I don't usually manage to catch it but got lucky this time) 0x3794b988 0x226e57 <thread_invoke+1213> 0x3794ba08 0x2270f6 <thread_block_reason+331> 0x3794ba78 0x227184 <thread_block+33> 0x3794ba98 0x29d846 <lck_mtx_lock_wait_x86+330> 0x3794baf8 0x298328 <lck_mtx_lock+504> 0x3794bb08 0x383de363 <com.trustdefender.kext.PacketFilter + 0x6363> 0x3794bd78 0x4c44dc <sflt_notify+92> 0x3794bda8 0x4b1b3f <soisdisconnecting+48> 0x3794bdc8 0x358582 <tcp_disconnect+77> 0x3794bde8 0x358631 <tcp_usr_detach+59> 0x3794be08 0x4ad59e <soclose_locked+742> 0x3794be68 0x4ad646 <soclose+66> 0x3794be88 0x4696fc <fo_close+13> 0x3794bef8 0x46b4ad <close_internal_locked+302> 0x3794bf38 0x46b57e <close_nocancel+141> 0x3794bf78 0x4edaf8 <unix_syscall64+617> 0x3794bfc8 0x29f43d <lo64_unix_scall+77> Usually, the second thread is long gone, and the socket's so_filt has been cleared... but we are still in the sflt_notify() callback, and detach hasn't been called. Also, the socket itself has been put into the socket cache, so its finished its life cycle. This doesn't seem like anything to do with my code simply because my code shouldn't affect when callbacks happen!.... has anyone seen anything like this before? Got any suggestions? Thanks Nick _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: NKE: sflt_detach and sflt_unregister - panics...
by Antoine Missout 09 Nov '10

09 Nov '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

NKE: sflt_detach and sflt_unregister - panics...
by Antoine Missout 08 Nov '10

08 Nov '10

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello, We are using the NKE interface to register filters (sflt_register - too bad we can't register once for many domain/type/protocol). When our driver is kextunloaded (user uninstalls or upgrades), we call sflt_unregister. Unfortunately, this does not detach our filters, preventing us from unloading our driver immediately. So we keep a list of all attached sockets (list is updated when sf_attach or sf_detach is called). The stop method goes like this: - sflt_unregister all our filters - call sflt_detach on all sockets in our list of attached sockets - sleep until sf_unregistered has been called for all our filters This works great 99% of the time. Except when sflt_detach panics. Not because the pointer is invalid, but because the socket is in the process of being closed. More exactly: panic(cpu 2 caller 0x3553c4): "tcp_lock: so=0xc0ad878 NO PCB! lr=0x4c3f8b lrh= 357342:3573b2 2:351d62 35747e:357547 4c44f6:4ad682 \n"@/SourceCache/xnu/xnu-1504.7.4/bsd/netinet/tcp_subr.c:2118 Backtrace (CPU 2), Frame : Return Address (4 potential args on stack) 0x925bb848 : 0x21b455 (0x5cf328 0x925bb87c 0x2238b1 0x0) 0x925bb898 : 0x3553c4 (0x5a6734 0xc0ad878 0x4c3f8b 0x879860) 0x925bb8c8 : 0x4ab120 (0xc0ad878 0x1 0x4c3f8b 0x4fdc95) 0x925bb8e8 : 0x4c3f8b (0xc0ad878 0x1 0x4c3cde 0x8dab8c0) $ atos -arch i386 -o /mach_kernel 0x4c3f8b 0x4ab120 0x3553c4 0x21b455 sflt_detach (in mach_kernel) + 45 socket_lock (in mach_kernel) + 44 tcp_lock (in mach_kernel) + 77 panic (in mach_kernel) + 445 tcp_lock panics because so_pcb has been cleared, but sf_detach has not yet been called in our filter. So how can we work around this ? sf_detach is called pretty late in the socket lifecycle, maybe it would be more safe to remove sockets from our list as soon as sock_evt_closing is sent (since it seems they'll inevitably be detached anyway) ? Thanks, Antoine _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kevent/Kqueue causing kernel panics
by Travis Athougies 06 Nov '10

06 Nov '10

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=L9yzxvv2zx0gGXE/+hicUUsIdRa0bUTkZs8a6lu7dj0=; b=eBYMxTz+7UgJMYN2kQzX5KyIor8m3Ge6WdqB9SHx3z/HO5iJu3ihFsiE67yodJxzrJ B43/Ompi2lB8fBgIpJ34MVVUzkqcX1R9Gq1hMKTIomSdB8lu7QgfhDaFmw8jbUeY98R+ dLP13TpswRXeFqPEHuird+Yk9HgsBQZffv0Ug= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DBTp2tQc4uBNMYwsiXQl3OPHWrS3C4CYA1cYfPgXq6a+fncYHml+bHYqCsIkw0Xe/v 5t1XgmfymgO/QAkbGZd1tVdNPairCgk+/0hC9ZOj8jNCzSYmqxlGjP4EKe1F73xAPjdV 0ms5cz2/G1omqhzC/OXimQIhw1TV/Sp1LT+7o= On Fri, Nov 5, 2010 at 8:20 PM, Terry Lambert <tlambert(a)apple.com> wrote: > This is not a support channel, and as Shantonu said, you should file a bug. That said: > I will > 0x4edaf8 is in unix_syscall64 (/SourceCache/xnu/xnu-1504.7.4/bsd/dev/i386/systemcalls.c:433). > 0x4701dc is in kevent (/SourceCache/xnu/xnu-1504.7.4/bsd/kern/kern_event.c:1225). > 0x46fdcc is in kevent_internal (/SourceCache/xnu/xnu-1504.7.4/bsd/kern/kern_event.c:1288). > 0x29d59a is in usimple_lock (/SourceCache/xnu/xnu-1504.7.4/osfmk/i386/locks_i386.c:352). > 0x21b455 is in panic (/SourceCache/xnu/xnu-1504.7.4/osfmk/kern/debug.c:307). > Thank you very much for the stack trace, I couldn't seem to find the debug symbols for my kernel from the developer site. This will definitely allow me to run my program while the bug is being fixed > You are getting a simple lock timeout. Simple locks spin for a very short time, and then if they can not be acquired in that time, they cause a panic. > Thanks for this > In this case, the simple lock in question is a call to kqlock(kq); at line 1287 of bsd/kern/kern_event.c in kevent_internal() called from kevent(). > Wow, thanks. > The lock is failing because it can't be acquired in the requisite time. Most probable causes, IMO, are attempting to run the non-server version of MacOS X under virtualization (virtualization can impact the absolute time locks are held, as well as the accuracy of the clocks by which the interval is measured), and a multithreaded program that is closing the kqueue in question out from under the kevent() system call. There are also other possibilities. > Running Mac OS X standard under a newly bought macbook pro, so no. And I never close the kqueue. Do you mean closing a file descriptor associated with the kqueue? > If I had to guess (which I do, since the only way to get sufficient information to fix the issue in this case is to do two machine debugging and/or set up a core dump server), I would have to say that since this is being ported from Linux, the cause is that the queue is getting closed by another thread under the mistaken assumption that since epoll is a cancellation point (i.e. the close will abort the system call), kevent on Mac OS X is as well. It is not. > Could you point me somewhere that would tell me how to get this set up? I have read the Apple Documentation. Is there anything else I should know? And no, this is definitely not being ported from linux. It's the other way around. I liked the BSD event system better, so I thought I'd do my main development on my macbook. However, that failed miserably, so I had to move to linux so I could actually run my program. > You should file a bug on this, but if you do, without including either the output of "showallstacks" from a two machine debug session, or a kernel core dump, OR including the sources necessary to reproduce the problem locally (assuming it DOES reproduce locally), it will end up as "Can Not Reproduce". So include the necessary information, or be prepared to be asked for it. > Thanks for the tip. > Either way, since it won't result in cancellation of the outstanding event, you should rethink your code to at least maintain a container structure in user space with a retain/release count on the kq to avoid closing the queue out from under it. If you need cancellation for the proper function of your program, you need to familiarize yourself with pthread_self() to save the kevent thread's thread id and pthread_kill() to allow a cancellation method on the container structure as a result of a desire to close the queue. > Like I said, I never release the kqueue, so I don't know how that could cause it. > -- Terry > > On Nov 5, 2010, at 6:07 PM, Travis Athougies wrote: >> I have a application that uses the kevent and kqueue API to provide >> asynchronous events to my application. Essentially, my program is >> completely event driven. I have my own event handling system which >> uses a global event queue to distribute events out to a number of >> threads (as many as the number of processors in the system). >> Periodically, kevent and kqueue are called to collect events on a >> number of sockets (I've only tested with one socket, since I can't do >> any more without a kernel panic), and then add these events to the >> global event queue. The event queue system works fine (it can handle >> thousands of simultaneous connections on linux using epoll* >> functions), however on mac, regardless of what I do, if I run my test >> program I get a KERNEL PANIC. Application bugs are one thing, but they >> should NEVER cause a kernel panic. Just wanted to know if anyone else >> has gotten this error and if they have, how they went about resolving >> it. The kernel panic message is below and I can provide source code if >> necessary. >> >> I'm using the Boehm GC with pthreads, if that means anything to you >> >> And this isn't a once in a while thing. This is every time I run the >> application, within a few test client runs. >> >> I've attached a kernel panic. I can provide sources, but keep in mind >> I'm not ready to make this software open-source. >> >> And the panic is always in the same place: locks_i386.c. >> >> -- >> Travis Athougies >> <Kernel_2010-11-05-151425_Travis-Athougiess-MacBook-Pro.panic> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com >> >> This email sent to tlambert(a)apple.com > > -- Travis Athougies _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kevent/Kqueue causing kernel panics
by Terry Lambert 06 Nov '10

06 Nov '10

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com This is not a support channel, and as Shantonu said, you should file a bug. That said: 0x4edaf8 is in unix_syscall64 (/SourceCache/xnu/xnu-1504.7.4/bsd/dev/i386/systemcalls.c:433). 0x4701dc is in kevent (/SourceCache/xnu/xnu-1504.7.4/bsd/kern/kern_event.c:1225). 0x46fdcc is in kevent_internal (/SourceCache/xnu/xnu-1504.7.4/bsd/kern/kern_event.c:1288). 0x29d59a is in usimple_lock (/SourceCache/xnu/xnu-1504.7.4/osfmk/i386/locks_i386.c:352). 0x21b455 is in panic (/SourceCache/xnu/xnu-1504.7.4/osfmk/kern/debug.c:307). You are getting a simple lock timeout. Simple locks spin for a very short time, and then if they can not be acquired in that time, they cause a panic. In this case, the simple lock in question is a call to kqlock(kq); at line 1287 of bsd/kern/kern_event.c in kevent_internal() called from kevent(). The lock is failing because it can't be acquired in the requisite time. Most probable causes, IMO, are attempting to run the non-server version of MacOS X under virtualization (virtualization can impact the absolute time locks are held, as well as the accuracy of the clocks by which the interval is measured), and a multithreaded program that is closing the kqueue in question out from under the kevent() system call. There are also other possibilities. If I had to guess (which I do, since the only way to get sufficient information to fix the issue in this case is to do two machine debugging and/or set up a core dump server), I would have to say that since this is being ported from Linux, the cause is that the queue is getting closed by another thread under the mistaken assumption that since epoll is a cancellation point (i.e. the close will abort the system call), kevent on Mac OS X is as well. It is not. You should file a bug on this, but if you do, without including either the output of "showallstacks" from a two machine debug session, or a kernel core dump, OR including the sources necessary to reproduce the problem locally (assuming it DOES reproduce locally), it will end up as "Can Not Reproduce". So include the necessary information, or be prepared to be asked for it. Either way, since it won't result in cancellation of the outstanding event, you should rethink your code to at least maintain a container structure in user space with a retain/release count on the kq to avoid closing the queue out from under it. If you need cancellation for the proper function of your program, you need to familiarize yourself with pthread_self() to save the kevent thread's thread id and pthread_kill() to allow a cancellation method on the container structure as a result of a desire to close the queue. -- Terry On Nov 5, 2010, at 6:07 PM, Travis Athougies wrote: > I have a application that uses the kevent and kqueue API to provide > asynchronous events to my application. Essentially, my program is > completely event driven. I have my own event handling system which > uses a global event queue to distribute events out to a number of > threads (as many as the number of processors in the system). > Periodically, kevent and kqueue are called to collect events on a > number of sockets (I've only tested with one socket, since I can't do > any more without a kernel panic), and then add these events to the > global event queue. The event queue system works fine (it can handle > thousands of simultaneous connections on linux using epoll* > functions), however on mac, regardless of what I do, if I run my test > program I get a KERNEL PANIC. Application bugs are one thing, but they > should NEVER cause a kernel panic. Just wanted to know if anyone else > has gotten this error and if they have, how they went about resolving > it. The kernel panic message is below and I can provide source code if > necessary. > > I'm using the Boehm GC with pthreads, if that means anything to you > > And this isn't a once in a while thing. This is every time I run the > application, within a few test client runs. > > I've attached a kernel panic. I can provide sources, but keep in mind > I'm not ready to make this software open-source. > > And the panic is always in the same place: locks_i386.c. > > -- > Travis Athougies > <Kernel_2010-11-05-151425_Travis-Athougiess-MacBook-Pro.panic> _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com > > This email sent to tlambert(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kevent/Kqueue causing kernel panics
by Shantonu Sen 06 Nov '10

06 Nov '10

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Kevent/Kqueue causing kernel panics
by Travis Athougies 06 Nov '10

06 Nov '10

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=3X3txZTgQRuNK0XcLDeq8QvIdYvYka9TIYTQ+pZXfAc=; b=oSdCePeqLta3BklU6ybwqyuX5w1GznlziXNLCTsgT3X89sjTn950xXSI6YiPZ4rrtg zdF7chdow1yypoYKCqFWZS+vs9Z+WYyv2YAB6mTUfZ7wHrONfKifSOYgFwYWi86WQapm mhqoF9odLCI8KCkPYo9/UjpaclgmoYlSRLDIM= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FayczJdl0E5EL0fCF4VVRk42Db02nsPkUsRkcVhPeVCD7T7KOzRUuBHiNAyUe0M0cQ tQVDnoMETYlQVX/GywO5VHbNKNqFf65RsRC/Ug5xlVPS4FjfW+QyyuvBdzOSLhR3seST AiKzfMX7yB3ccmS1HiJ/XEoKYc+tNqYTzbbUA= I have a application that uses the kevent and kqueue API to provide asynchronous events to my application. Essentially, my program is completely event driven. I have my own event handling system which uses a global event queue to distribute events out to a number of threads (as many as the number of processors in the system). Periodically, kevent and kqueue are called to collect events on a number of sockets (I've only tested with one socket, since I can't do any more without a kernel panic), and then add these events to the global event queue. The event queue system works fine (it can handle thousands of simultaneous connections on linux using epoll* functions), however on mac, regardless of what I do, if I run my test program I get a KERNEL PANIC. Application bugs are one thing, but they should NEVER cause a kernel panic. Just wanted to know if anyone else has gotten this error and if they have, how they went about resolving it. The kernel panic message is below and I can provide source code if necessary. I'm using the Boehm GC with pthreads, if that means anything to you And this isn't a once in a while thing. This is every time I run the application, within a few test client runs. I've attached a kernel panic. I can provide sources, but keep in mind I'm not ready to make this software open-source. And the panic is always in the same place: locks_i386.c. -- Travis Athougies _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com Kernel_2010-11-05-151425_Travis-Athougiess-MacBook-Pro.panic

1 0