site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=SgMq60aOtGwUxAAndmEpVfrFpfALlSV08Oy8DbvXDUQ=; b=l24EYhsye6hZ6hSqpv76RIHHr5/2MPI69yvqE68PgKWxk9X+xOzSgtb2Otzfj447wL YDRTAGpKwVpbXqyVNzaa+idQZ1uG569TcmCxeuylt0NsbCL8zhf1Qw+GBLLBpkqHWGwC MR3BmSZZxwYhozIIDvZAUBeI0dPSZTlvNoj7w= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=uExAGCLmb+I8Apj0RmZbRckE5RelhYUIp4PjK5xTCUZIPBuY2RvYNth2mcMW5RW7tm 1kWyIFAM81ekp797LpuRhecFaTycld8AeoJJdCpehnXoFrJZ0rp5JlEOCERnzGCQpRKG TbfIQUxKpkLAt/FxDtbS7K+giuzf9eAfsNQkw= Terry - 1. I've double checked the code. Within the below line of code: err_wait = errno; the errno is actually the macro from /usr/include/sys/errno.h - `#define errno (*__error())` To this end, I think the header file is included, unless we are talking about different files. 2. Also, I looking further into the issue, I have noticed that though the fsync() call ( see code below) if(fsync(aio.aio_fildes) < 0){ // For some reason, TH1 is waked-up while TH2 is executing fsync().... lerror = (int)errno; }; is waking up the TH1, fsync(...) itself is returning with no fault... So, my original statement that fsync (...) produces EBADF (9) may be not correct. ( Unless the fault is reported to the wrong thread - TH1, rather then TH2)... 3. Tracing assembly code showed the following: after the EBADF(9) appeared within TH1, the following calls of sem_wait(&sem) are translated into some syscall, which returning 9 in %rax register, and then cerror call... That is all findings for now. Thanks for the attention. I hope above will provide some clue and helps to answer the question. Michael. On Sat, Oct 4, 2008 at 1:57 AM, Terry Lambert <tlambert@apple.com> wrote:
You are looking at the global errno because you have not got the macro errno in scope because you have not included the appropriate header files for your application.
-- Terry
On Oct 3, 2008, at 6:05 PM, Michael Andronov wrote:
Patrick -
Thank you very much for the speedy reply to my message.
You're asking "how to distinguish errno (global) from errno ( thread local) on OS X 10.5 Leopard?", but I don't think that question even makes any sense;
Ok, may be I was not too clear what I was looking for. Let me re-phrase and make the situation more specific....
1. there are 2 threads within application.
2. thread TH1 is coming to the point : ... do{ if((rst_wait=sem_wait(&sem)) < 0) // At this point, the thread is preempted and `sleeping`, waiting being waked-up err_wait = errno; }while ( (rst_wait <0) && ((err_wait == EINTR) || (err_wait == 9))); ...
3. second thread, TH2 is coming to the point: ... if(fsync(aio.aio_fildes) < 0){ // For some reason, TH1 is waked-up while TH2 is executing fsync().... lerror = (int)errno; }; ..... sem_post(&sem); // TH1 is expected being waked-up at this point! ....
The behavior I'm observing - thread TH1 is waked-up while TH2 is within library call fsync(...); In addition, the resulted errno - err_wait - is set up to EBADF ( 9), which is not even in the spec /manual for sem_wait(), ( but in the spec /manual for fsync()....). (The expected behavior : - later within the code, TH2 is calling sem_post(&sem). At this point, I'm expecting TH1 to be waken up. ( That is the behavior of the code on Linux machine). OR - the TH1 is waked up with the code ` [EINTR] The call was interrupted by a signal.` )
Also, as soon as the err_wait became 9, the consequent calls to sem_wait() return immediately, with the same err_wait == 9.
Consistence, which I can reproduce above with, makes me believe that TH1 is actually reading the `global` errno. or errno, which was set/triggered by TH2.
I have found a few notes in this forum archives, saying that there were racing condition within int * __error() function implementation itself... The behavior I'm observing - fitting `profile' of the reported bug.... But this bug was dated to ~2002, and it seems was not connected to current OS X release.
Also, I have found in the couple of books the references that libc implementation supports 2 copies of errno - one `global`, and one, which is `thread oriented/related`.
Basically, I'm a bit puzzled with above behavior of the code, and looking for work around and/or fix.
Any ideas will be highly appreciated. Once again, thanks for your attention to this matter.
Michael.
On Fri, Oct 3, 2008 at 7:40 PM, Patrick Rutkowski <rutski89@gmail.com> wrote: Using the symbol "errno" is the right thing to do in all cases, threaded or non-threaded. This is why it's usually implemented as a macro, so that under the hood it's really a call to some OS specific function get the thread's local errno, e.g.:
./sys/errno.h:#define errno (*__error())
You're asking "how to distinguish errno (global) from errno ( thread local) on OS X 10.5 Leopard?", but I don't think that question even makes any sense; there's no such thing as a global errno, as far as I can tell.
-Patrick
On Oct 3, 2008, at 6:56 PM, Michael Andronov wrote:
Hi,
I am presently debugging an application, which has 2 threads:
1. First thread - TH1 - is waiting to be waked up within the function sem_wait(...)
2. Second thread - TH2 - is executing some code. Within such code, there is a call for fsync(...) function.
The behavior is that if fsync() function within TH2 is failing, then TH1 is returning form sem_wait(...) with errno EBADF ( int 9).
The only explanation I see is that for some reason global errno is checked within TH1 instead of thread local.
The code , in C++, is compiled with `-pthread` flag, under OS X 10.5...
My question is how to distinguish errno (global) from errno ( thread local) on OS X 10.5 Leopard?
Thanks for kind attention to this matter.
Michael.
P.S> I have seen same posting about similar issue dated 2002, but the `fixes` seems not working on 10.5...
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/rutski89%40gmail.com
This email sent to rutski89@gmail.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/ma5645%40gmail.com
This email sent to ma5645@gmail.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com
This email sent to tlambert@apple.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/ma5645%40gmail.com
This email sent to ma5645@gmail.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com
participants (1)
-
Michael Andronov