Thoughts on this pthreads bug: why release O_NONBLOCK in _exit?
I've been studying a few things in pthreads to figure out a bug that's
had me banging my head against a wall. I'd be interested in knowing
what peoples' thoughts are.
The basic scenario is that a fd loses its schedulability after the
process calls daemon(). To review:
The current pthreads implementation requires fds to be marked
O_NONBLOCK (which pthreads manages itself) to allow scheduling to work
properly.
The daemon() library call's life (for the purposes of this discussion)
is to fork. The parent dies by calling _exit(0), and the child goes
on.
The _exit routine in libc_r turns off the O_NONBLOCK flag on all file
descriptors, except those which the program turned it on for.
Now, the problem.
The forked parent and child, of course, are sharing fds. So when the
forked child exits, the parent's fds have their O_NONBLOCK flags
toggled off. If the parent is still running multithreaded, this
creates a scheduling problem.
I've included a condensed version of the code I've been using to test
this below. It's enough to demonstrate the problem, if not the normal
symptoms.
What I can't figure out is why libc_r's _exit toggles off the
O_NONBLOCKs.
Any thoughts?
Thanks,
joelh
#include
#include
#include
#include
#include
#include
int
main(int argc, char *argv)
{
pid_t pid;
int fd;
fd = socket(PF_UNIX, SOCK_DGRAM, 0);
printf("flags after open: %x\n", _thread_sys_fcntl(fd, F_GETFL));
fflush(stdout);
pid = fork();
if (pid != 0) {
printf("flags after fork in parent: %x\n",
_thread_sys_fcntl(fd, F_GETFL));
fflush(stdout);
/* We use _exit instead of exit to imitate what daemon()
* does. */
_exit(0);
} else {
sleep(1); /* Give the parent time to die */
printf("flags after fork in child: %x\n",
_thread_sys_fcntl(fd, F_GETFL));
exit(0);
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenSSH + Kerberos 5 + PAM
David Terrell wrote: > On Tue, Aug 28, 2001 at 04:56:06PM -0700, Gordon Tetlow wrote: > >>I like Kerberos 5 and it's ability to use tickets so I don't have to type >>passwords whenever I login/su/need to authenticate myself. So it *really* >>annoys me that there is a pam_krb5 module that allows you to authenticate >>against a Kerberos 5 principal but it won't accept any tickets that I try >>to pass to it. I've done a bit of research on the matter and am told that >>it is a limitation of the PAM API. So be it. >> >>I suppose I can install kerberos' version of telnet/ftp/rsh/rlogin/etc, >>but again, I'm lazy (I *am* a system administrator). I was thinking that >>it would be nice to have Kerberos 5 authentication available in OpenSSH >>since that comes with the distribution and is even enabled by default. >> >>So, being lazy, I decided to trawl the net seeing if I could find anyone >>that has already done the work. Bingo! >>http://www.sxw.org.uk/computing/patches/openssh.html The author claims >>that it works with both KTH and MIT Kerberos 5 implementations (I've tried >>it on MIT and it works like a charm). I was wondering if there was any >>interest in integrating this, or if it is considered too large a patch. If >>there is interest, I would be willing to do the legwork to try and >>integrate it (although there is probably lots of cases to deal with). >> > > Patches have been circulated on openssh-unix-dev to apply kerb5 to > the upstream OpenBSD source. In fact, krb5 support is in protocol 1 > in the OpenBSD tree now, and I'd speculate that protocol 2 support > will be in by the time 3.0 ships in December, since OpenBSD 3.0 will > ship with Kerb5 (Heimdal) in the base. I'm not that current on krb5, but I do have to ask if the CERT issues have been resolved? My info on this is a little old, but I recall CERT advisories last year on serious vulnerabilities in krb5 at the time, it would be nice to know if they have been fixed. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Loader problems
In a message dated 8/29/01 7:34:47 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: > the second > > > > partition seems fine. Backspacing over the characters and hitting return > > manually and the machine boots normally. Both partitions are using the > BTX > > loader v1.01 > > > > Any ideas? > > Sounds like you're getting garbage in the keyboard buffer. 8( > > How new is the motherboard/BIOS? > Also, if there was garbage in the keyboard buffer, wouldnt it affect both partiions (and not just the fist as in this case)? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Loader problems
On Wed, 29 Aug 2001 [EMAIL PROTECTED] wrote: > Fairly new. Other disks work ok, and we use this motherboard on lots of > systems. Its something with the setup...the 2 freebsds on a disk I think. > > Bryan If it's any consolation, my -current box started requiring me to hit enter to get past the loader a few weeks ago. I didn't bother trying to track it down, but it sounds related. If there's something to check, I'll be glad to do so. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Loader problems
In a message dated 8/29/01 7:34:47 PM Eastern Daylight Time, [EMAIL PROTECTED] writes: > > I have a hard drive with 2 versions of freebsd (4.1 and 4.2) loaded on it. > > They boot and load ok, but when 4.1 is soft-rebooted, it stops at the boot: > > > prompt and 3 strange characters are displayed (not alphanumeric)...the > second > > > > partition seems fine. Backspacing over the characters and hitting return > > manually and the machine boots normally. Both partitions are using the > BTX > > loader v1.01 > > > > Any ideas? > > Sounds like you're getting garbage in the keyboard buffer. 8( > > How new is the motherboard/BIOS? > Fairly new. Other disks work ok, and we use this motherboard on lots of systems. Its something with the setup...the 2 freebsds on a disk I think. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Proposed Utility - detach(1)
> I would appreciate comments on the usefulness of a utility which would
> allow one to detach a process from a TTY. I imagine the utility would
> be very small and just call daemon(3) and execlp(3).
1) cd /usr/ports/sysutils/detach
have fun...
2) the code itself is rather simple and I wrote such detach.c by
myself on FreeBSD 3.4 before I had a chance to look into ports
collection. Here it is:
/*==
* detach.c
*--
* Executes given as arguments programs having
* detached TTY at first.
*
* by Poige, [EMAIL PROTECTED]
*==
*/
#include
#include
#include
int main(int argc, char **argv)
{
/* executes another programs having detached
* tty at first
*/
return ! (
argv[1]
&& (fork () == 0)
&& (setsid () > 0)
&& (fork () == 0)
&& (execvp (argv[1], argv + 1) > 0)
);
}
> Would a utility like this be useful?
yes
> Is this functionality already available in a system utility?
in ports...
> Best regards,
> Mike Barcroft
--
Igormailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Fault type in the page fault handler
Hi, Is it possible to figure out the fault type(READ or WRITE fault) from inside the page fault handler in user space? I can get the faulting address fine but I have trouble figuring out the fault type. I looked at the i386/i386/machdep.c but couldn't find anything about the access/fault type. Any help would be appreciated. Thanks, Murali To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OpenSSH + Kerberos 5 + PAM
On Tue, Aug 28, 2001 at 04:56:06PM -0700, Gordon Tetlow wrote: > I like Kerberos 5 and it's ability to use tickets so I don't have to type > passwords whenever I login/su/need to authenticate myself. So it *really* > annoys me that there is a pam_krb5 module that allows you to authenticate > against a Kerberos 5 principal but it won't accept any tickets that I try > to pass to it. I've done a bit of research on the matter and am told that > it is a limitation of the PAM API. So be it. > > I suppose I can install kerberos' version of telnet/ftp/rsh/rlogin/etc, > but again, I'm lazy (I *am* a system administrator). I was thinking that > it would be nice to have Kerberos 5 authentication available in OpenSSH > since that comes with the distribution and is even enabled by default. > > So, being lazy, I decided to trawl the net seeing if I could find anyone > that has already done the work. Bingo! > http://www.sxw.org.uk/computing/patches/openssh.html The author claims > that it works with both KTH and MIT Kerberos 5 implementations (I've tried > it on MIT and it works like a charm). I was wondering if there was any > interest in integrating this, or if it is considered too large a patch. If > there is interest, I would be willing to do the legwork to try and > integrate it (although there is probably lots of cases to deal with). Patches have been circulated on openssh-unix-dev to apply kerb5 to the upstream OpenBSD source. In fact, krb5 support is in protocol 1 in the OpenBSD tree now, and I'd speculate that protocol 2 support will be in by the time 3.0 ships in December, since OpenBSD 3.0 will ship with Kerb5 (Heimdal) in the base. -- David Terrell | "Any sufficiently advanced technology Prime Minister, Nebcorp | is indistinguishable from a rigged demo." [EMAIL PROTECTED] | - Brian Swetland http://wwn.nebcorp.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FW: Interesting Router Question
On Wed, 29 Aug 2001, Mike Silbersack wrote: > As to what type of flood that is - you can't tell with that version of > freebsd. It could've been a UDP or TCP flood (ACK or SYN). It actually > couldn't have been a icmp flood, that version of freebsd didn't limit icmp > responses. (Even though the message implies it, yes. This has been > clarified in 4.3.) Although there's no canonical log message, you *may* be able to derive something from watching changes in netstat -s. J To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PLEASE REVIEW: loader fix for gzipped kernels
In article <[EMAIL PROTECTED]>, Matt Dillon <[EMAIL PROTECTED]> wrote: >I'll give it a quick test after you commit it (I can combine the >test with some other work I'm doing). Thanks. I've committed it, and it should hit the mirrors within the next hour. I tested it with both gzipped and full-size kernels, in -current and -stable on the i386 and in -slightlystale on the Alpha. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PLEASE REVIEW: loader fix for gzipped kernels
:In article <[EMAIL PROTECTED]>, :John Baldwin <[EMAIL PROTECTED]> wrote: :> :> Looks good to me, but I'm only somewhat familiar with libstand. :) : :Thanks for taking a look at it. Matt Dillon also reviewed it and gave :it a clean bill of health. He made a suggestion for making the code a :bit smaller. I'll incorporate that and then commit it to -current. : :John I'll give it a quick test after you commit it (I can combine the test with some other work I'm doing). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libc_r, signals and modifying sigcontext
On Thu, 30 Aug 2001, Fuyuhiko Maruyama wrote:
> At Wed, 29 Aug 2001 14:31:25 -0400 (EDT),
> Daniel Eischen wrote:
> >
> > On Thu, 30 Aug 2001, Fuyuhiko Maruyama wrote:
> > > Hi all,
> > >
> > > [SNIP]
> > >
> > > How do you think to add sigreturn function into libc_r?
> >
> > Your implementation of sigreturn is not correct for our threads
> > library. You don't need the strong reference in -current.
> Does it need in -stable?
I'm not sure.
> > The signal mask in the ucontext_t is the _process_ signal
> > mask. This is not the threads signal mask which can be
> > different. It may work in your case because your threads
> > don't change their signal mask, so it may be the same as
> > the process signal mask.
> Right, I made mistakes, my sample is too simplified. Now I understand
> it, thanks.
>
> > I'm not sure what sigreturn should do in a threaded environment,
> > particularly if it should restore the threads signal mask or
> > not.
> At least on Solaris, we can restore sigmask for thread at signal
> handler using setcontext(uc) to return from signal handler, but I'm
> not sure ucontext in Solaris is whether per thread object or per
> process object. On the other hand, we cannot restore the sigmask for
> thread when we return from signal handler with libc_r. So we need
> similar function as Solaris's setcontext, of course setcontext may do
> more than sigreturn do. And the most important fact is we cannot
> implement sigreturn in user programs because it need to know the
> actual implementation of thread library.
sigreturn should be pretty compatible with setcontext. You can
do a setcontext on the ucontext_t argument passed to a signal
handler to restore the state prior to the signal. This is exactly
what sigreturn does. FreeBSD doesn't have {get,set,make}context
yet.
> Java VM needs this function. My previous example explains how JIT
> compiled codes in Java VM works. Actual codes which may cause SIGSEGV
> or SIGFPE does not always raise signals.
>
> > In order to make it work the you want it to, and I'm
> > not sure that is the correct thing yet, you need to change
> > the signal mask in the ucontext before the signal handler
> > is invoked. This would be done somewhere in uthread_sig.c.
> > You would put the threads signal mask (before OR'ing in
> > the sa_mask from the installed handler) into the ucontext.
> > This would make the ucontext passed to a signal handler
> > contain that threads signal mask, not the process signal
> > mask. Then when implementing sigreturn, you restore the
> > threads signal mask from the ucontext, place the process
> > signal mask in the ucontext, and _thread_sys_sigreturn().
> >
> > Here's a quick (uncompiled, untested) attempt at a fix.
>
> Your patch seems to work, yes I tried with test.c modified to specify
> per thread sigmask. But now I have worry about when there are another
> signals pended.
I think that when there are multiple signals pending, the kernel
installs multiple trampolines, so when one signal handler returns
the next signal handler is called. If you sigreturn, setcontext,
or just exit the signal handler normally, the next signal handler
will be called. If you longjmp out of the handler though, you
bypass all the other pending handlers and lose those signals.
I've tested this under -current.
> The actual work needed for sigreturn is restore the
> sigmask to unblock the very signal masked at uthread_sig.c(line 1070)
> temporarily. Using thread->sigmask for sigreturn may do overwork.
> How do you think about this?
If there were multiple trampolines set up by the kernel, then
the threads library will get the next signal when the thread
sigreturns or exits the signal handler normally. There may be
a small race if two or more signals happen really close together
and the threads library installs multiple signal frames for
a thread before getting a chance to execute that thread. In
this case, a sigreturn might bypass the other frames that have
been setup.
If you install the signal handlers with the sa_mask all set,
then this won't happen and all signals will be masked for the
thread while it is in the signal handler.
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PLEASE REVIEW: loader fix for gzipped kernels
In article <[EMAIL PROTECTED]>, John Baldwin <[EMAIL PROTECTED]> wrote: > > Looks good to me, but I'm only somewhat familiar with libstand. :) Thanks for taking a look at it. Matt Dillon also reviewed it and gave it a clean bill of health. He made a suggestion for making the code a bit smaller. I'll incorporate that and then commit it to -current. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: PLEASE REVIEW: loader fix for gzipped kernels
On 29-Aug-01 John Polstra wrote: > I would appreciate another pair of eyes on the attached patch before > I commit it. Looks good to me, but I'm only somewhat familiar with libstand. :) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libc_r, signals and modifying sigcontext
At Wed, 29 Aug 2001 14:31:25 -0400 (EDT),
Daniel Eischen wrote:
>
> On Thu, 30 Aug 2001, Fuyuhiko Maruyama wrote:
> > Hi all,
> >
> > I'm also wondering how to use signals to handle runtime exceptions
> > such as SIGFPE and SIGSEGV in pthread application. These signals are
> > often used by implementation of Java VM to handle Java's runtime
> > exceptions. Almost same scheme works fine in non-pthread application
> > but it doesn't in pthread application.
> >
> > `test.c' gives the simplified version of this problem (the program
> > assumes x86). When I use _thread_sys_sigreturn someone suggests, the
> > first signal is caught by signal handler on the current thread that
> > cause the exception but signals after second attempts are never caught
> > on the current thread. This is because the sigmask for signal handler
> > thread, the current thread at first signal, is masked at
> > uthread_sig.c(line 1070) and it isn't recovered when
> > _thread_sys_sigreturn is called.
> >
> > So we need `sigreturn' function for libc_r instead of using
> > _thread_sys_sigreturn. `uthread_sigreturn.c` gives a simple
> > implementation of sigreturn for 4.3-STABLE(4.4-RC). When I use
> > sigreturn (implemented at `uthread_sigreturn.c') instead
> > of_thread_sys_sigreturn in `test.c', the program works as I expected.
> >
> >
> > How do you think to add sigreturn function into libc_r?
>
> Your implementation of sigreturn is not correct for our threads
> library. You don't need the strong reference in -current.
Does it need in -stable?
> The signal mask in the ucontext_t is the _process_ signal
> mask. This is not the threads signal mask which can be
> different. It may work in your case because your threads
> don't change their signal mask, so it may be the same as
> the process signal mask.
Right, I made mistakes, my sample is too simplified. Now I understand
it, thanks.
> I'm not sure what sigreturn should do in a threaded environment,
> particularly if it should restore the threads signal mask or
> not.
At least on Solaris, we can restore sigmask for thread at signal
handler using setcontext(uc) to return from signal handler, but I'm
not sure ucontext in Solaris is whether per thread object or per
process object. On the other hand, we cannot restore the sigmask for
thread when we return from signal handler with libc_r. So we need
similar function as Solaris's setcontext, of course setcontext may do
more than sigreturn do. And the most important fact is we cannot
implement sigreturn in user programs because it need to know the
actual implementation of thread library.
Java VM needs this function. My previous example explains how JIT
compiled codes in Java VM works. Actual codes which may cause SIGSEGV
or SIGFPE does not always raise signals.
> In order to make it work the you want it to, and I'm
> not sure that is the correct thing yet, you need to change
> the signal mask in the ucontext before the signal handler
> is invoked. This would be done somewhere in uthread_sig.c.
> You would put the threads signal mask (before OR'ing in
> the sa_mask from the installed handler) into the ucontext.
> This would make the ucontext passed to a signal handler
> contain that threads signal mask, not the process signal
> mask. Then when implementing sigreturn, you restore the
> threads signal mask from the ucontext, place the process
> signal mask in the ucontext, and _thread_sys_sigreturn().
>
> Here's a quick (uncompiled, untested) attempt at a fix.
>
> Index: uthread/uthread_sig.c
> ===
> RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_sig.c,v
> retrieving revision 1.25.2.8
> diff -u -r1.25.2.8 uthread_sig.c
> --- uthread/uthread_sig.c 2001/07/06 12:31:25 1.25.2.8
> +++ uthread/uthread_sig.c 2001/08/29 18:29:39
> @@ -1063,6 +1063,7 @@
> sizeof(psf->uc));
> memcpy(&psf->siginfo, &_thread_sigq[psf->signo - 1].siginfo,
> sizeof(psf->siginfo));
> + psf->uc.uc_sigmask = thread->sigmask;
> }
>
> /* Setup the signal mask: */
>
>
>
> #include
> #include
> #include
> #include
>
> #ifdef _THREAD_SAFE
> #include
> #include "pthread_private.h"
>
> int
> _sigreturn(ucontext_t *ucp)
> {
> _thread_run->sigmask = ucp->uc_sigmask;
> ucp->uc_sigmask = _process_sigmask;
> return (_thread_sys_sigreturn(ucp));
> }
>
> __strong_reference(_sigreturn, sigreturn);
> #endif
Your patch seems to work, yes I tried with test.c modified to specify
per thread sigmask. But now I have worry about when there are another
signals pended. The actual work needed for sigreturn is restore the
sigmask to unblock the very signal masked at uthread_sig.c(line 1070)
temporarily. Using thread->sigmask for sigreturn may do overwork.
How do you think about this?
--
Fuyuhiko MARUYAMA <[EMAIL PROTECTED]>
Matsuoka laboratory,
Department of Mathematical and
BSDCon 2002 - deadline extension for abstracts (fwd)
This just popped up on the Darwin development list, but might also be of interest to FreeBSD developers interested in submitting a paper. Apparently I wasn't the only one who needed a deadline :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services -- Forwarded message -- Date: Wed, 29 Aug 2001 11:12:11 -0700 From: Brian Cassidy <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Ron Dumont <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: BSDCon 2002 - deadline extension for abstracts Darwin developers, The chairperson of BSDCon 2002 has extended the deadline for paper abstract submissions by one week. Paper abstracts must now be submitted by Friday September 7. If you weren't sure that you could meet the original deadline, you now have a bit more leeway. So please, if you have any interest in sharing your work on Darwin with the rest of the BSD community, write up a short abstract and send it to [EMAIL PROTECTED] . Please visit the BSDCon 2002 web site for more information or to access the web submission form: http://www.usenix.org/events/bsdcon02/cfp/ Thanks again, The Darwin Team. ___ darwin-development mailing list [EMAIL PROTECTED] http://www.lists.apple.com/mailman/listinfo/darwin-development To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PLEASE REVIEW: loader fix for gzipped kernels
On Wed, Aug 29, 2001 at 11:27:20AM -0700, John Polstra wrote: > I would appreciate another pair of eyes on the attached patch before > I commit it. > > I have been working with gzipped kernels a lot lately, and have > noticed that when the loader tries to load certain kernels, it fails > with the message "elf_loadexec: cannot seek". I tracked this down to > a bug in "src/lib/libstand/lseek.c", which is fixed by this patch. so that's why the -CURRENT snapshot i was trying to install last night refused to boot... exactly that error. damn that was irritating me. i thought i was getting a corrupt iso image or something. -- garrett rooney Unix was not designed to stop you from [EMAIL PROTECTED] doing stupid things, because that would http://electricjellyfish.net/ stop you from doing clever things. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libc_r, signals and modifying sigcontext
On Thu, 30 Aug 2001, Fuyuhiko Maruyama wrote:
> Hi all,
>
> I'm also wondering how to use signals to handle runtime exceptions
> such as SIGFPE and SIGSEGV in pthread application. These signals are
> often used by implementation of Java VM to handle Java's runtime
> exceptions. Almost same scheme works fine in non-pthread application
> but it doesn't in pthread application.
>
> `test.c' gives the simplified version of this problem (the program
> assumes x86). When I use _thread_sys_sigreturn someone suggests, the
> first signal is caught by signal handler on the current thread that
> cause the exception but signals after second attempts are never caught
> on the current thread. This is because the sigmask for signal handler
> thread, the current thread at first signal, is masked at
> uthread_sig.c(line 1070) and it isn't recovered when
> _thread_sys_sigreturn is called.
>
> So we need `sigreturn' function for libc_r instead of using
> _thread_sys_sigreturn. `uthread_sigreturn.c` gives a simple
> implementation of sigreturn for 4.3-STABLE(4.4-RC). When I use
> sigreturn (implemented at `uthread_sigreturn.c') instead
> of_thread_sys_sigreturn in `test.c', the program works as I expected.
>
>
> How do you think to add sigreturn function into libc_r?
Your implementation of sigreturn is not correct for our threads
library. You don't need the strong reference in -current.
The signal mask in the ucontext_t is the _process_ signal
mask. This is not the threads signal mask which can be
different. It may work in your case because your threads
don't change their signal mask, so it may be the same as
the process signal mask.
I'm not sure what sigreturn should do in a threaded environment,
particularly if it should restore the threads signal mask or
not. In order to make it work the you want it to, and I'm
not sure that is the correct thing yet, you need to change
the signal mask in the ucontext before the signal handler
is invoked. This would be done somewhere in uthread_sig.c.
You would put the threads signal mask (before OR'ing in
the sa_mask from the installed handler) into the ucontext.
This would make the ucontext passed to a signal handler
contain that threads signal mask, not the process signal
mask. Then when implementing sigreturn, you restore the
threads signal mask from the ucontext, place the process
signal mask in the ucontext, and _thread_sys_sigreturn().
Here's a quick (uncompiled, untested) attempt at a fix.
Index: uthread/uthread_sig.c
===
RCS file: /opt/FreeBSD/cvs/src/lib/libc_r/uthread/uthread_sig.c,v
retrieving revision 1.25.2.8
diff -u -r1.25.2.8 uthread_sig.c
--- uthread/uthread_sig.c 2001/07/06 12:31:25 1.25.2.8
+++ uthread/uthread_sig.c 2001/08/29 18:29:39
@@ -1063,6 +1063,7 @@
sizeof(psf->uc));
memcpy(&psf->siginfo, &_thread_sigq[psf->signo - 1].siginfo,
sizeof(psf->siginfo));
+ psf->uc.uc_sigmask = thread->sigmask;
}
/* Setup the signal mask: */
#include
#include
#include
#include
#ifdef _THREAD_SAFE
#include
#include "pthread_private.h"
int
_sigreturn(ucontext_t *ucp)
{
_thread_run->sigmask = ucp->uc_sigmask;
ucp->uc_sigmask = _process_sigmask;
return (_thread_sys_sigreturn(ucp));
}
__strong_reference(_sigreturn, sigreturn);
#endif
--
Dan Eischen
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
PLEASE REVIEW: loader fix for gzipped kernels
I would appreciate another pair of eyes on the attached patch before
I commit it.
I have been working with gzipped kernels a lot lately, and have
noticed that when the loader tries to load certain kernels, it fails
with the message "elf_loadexec: cannot seek". I tracked this down to
a bug in "src/lib/libstand/lseek.c", which is fixed by this patch.
Here is the bug that it fixed. Libstand maintains a read-ahead buffer
for each open file, so that it can read in chunks of 512 bytes for
greater efficiency. When the loader tries to lseek forward in a file
by a small amount, it sometimes happens that the target file offset is
already in the read-ahead buffer. But the existing code in lseek.c
simply discards the contents of that buffer and does a seek directly
on the underlying file. This results in an attempt to seek backwards
in the file, since some of the data has already been read into the
read-ahead buffer. Gzipped data streams cannot seek backwards, so an
error is returned.
The code added by the patch checks to see if the desired file offset
is already in the read-ahead buffer. If it is, the code simply
adjusts the buffer pointer and length, thereby avoiding a reverse seek
on the gzipped data stream.
The bug is present in both -current and -stable. This patch is
relative to -stable, but it applies cleanly to -current too.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
Index: lseek.c
===
RCS file: /home/ncvs/src/lib/libstand/lseek.c,v
retrieving revision 1.1.1.1.6.1
diff -u -r1.1.1.1.6.1 lseek.c
--- lseek.c 2000/09/10 01:32:06 1.1.1.1.6.1
+++ lseek.c 2001/08/29 17:45:21
@@ -70,6 +70,8 @@
off_t
lseek(int fd, off_t offset, int where)
{
+struct stat sb;
+off_t bufpos, filepos, target;
struct open_file *f = &files[fd];
if ((unsigned)fd >= SOPEN_MAX || f->f_flags == 0) {
@@ -94,6 +96,39 @@
return (-1);
}
return (f->f_offset);
+}
+
+/*
+ * If there is some unconsumed data in the readahead buffer and it
+ * contains the desired offset, simply adjust the buffer pointers.
+ */
+if (f->f_ralen != 0) {
+ if ((filepos = (f->f_ops->fo_seek)(f, (off_t)0, SEEK_CUR)) == -1)
+ return (-1);
+ bufpos = filepos - f->f_ralen;
+ switch (where) {
+ case SEEK_SET:
+ target = offset;
+ break;
+ case SEEK_CUR:
+ target = bufpos + offset;
+ break;
+ case SEEK_END:
+ if ((f->f_ops->fo_stat)(f, &sb) == -1 || sb.st_size == -1) {
+ errno = EOFFSET;
+ return (-1);
+ }
+ target = sb.st_size + offset;
+ break;
+ default:
+ errno = EINVAL;
+ return (-1);
+ }
+ if (bufpos <= target && target < filepos) {
+ f->f_raoffset += target - bufpos;
+ f->f_ralen -= target - bufpos;
+ return (target);
+ }
}
/*
Re: libc_r, signals and modifying sigcontext
I missed one thing to say, When I try to know what's happen in the libc_r, I use libc_r with DEBUG_SIGNAL defined. There seems to be something wrong with libc_r's signal handler when it cannot find the thread to handle signal, libc_r seems to refer some phantom thread that doesn't exist and it may cause another fault. If you also use libc_r with DEBUG_SIGNAL defined, you can see the problem during execution of my previous sample program (test.c). Thanks. -- Fuyuhiko MARUYAMA <[EMAIL PROTECTED]> Matsuoka laboratory, Department of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Loader problems
I have a hard drive with 2 versions of freebsd (4.1 and 4.2) loaded on it. They boot and load ok, but when 4.1 is soft-rebooted, it stops at the boot: prompt and 3 strange characters are displayed (not alphanumeric)...the second partition seems fine. Backspacing over the characters and hitting return manually and the machine boots normally. Both partitions are using the BTX loader v1.01 Any ideas? Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libc_r, signals and modifying sigcontext
Hi all, I'm also wondering how to use signals to handle runtime exceptions such as SIGFPE and SIGSEGV in pthread application. These signals are often used by implementation of Java VM to handle Java's runtime exceptions. Almost same scheme works fine in non-pthread application but it doesn't in pthread application. `test.c' gives the simplified version of this problem (the program assumes x86). When I use _thread_sys_sigreturn someone suggests, the first signal is caught by signal handler on the current thread that cause the exception but signals after second attempts are never caught on the current thread. This is because the sigmask for signal handler thread, the current thread at first signal, is masked at uthread_sig.c(line 1070) and it isn't recovered when _thread_sys_sigreturn is called. So we need `sigreturn' function for libc_r instead of using _thread_sys_sigreturn. `uthread_sigreturn.c` gives a simple implementation of sigreturn for 4.3-STABLE(4.4-RC). When I use sigreturn (implemented at `uthread_sigreturn.c') instead of_thread_sys_sigreturn in `test.c', the program works as I expected. How do you think to add sigreturn function into libc_r? P.S. The manual page for sigreturn.2 is too old. -- Fuyuhiko MARUYAMA <[EMAIL PROTECTED]> Matsuoka laboratory, Department of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. test.c uthread_sigreturn.c
Re: memory + apache
On Tue, 28 Aug 2001, Dan wrote: : :i am seeing problems where apache is running into swap at times. :When all is said and done...i see alot of available memory from top :and alot still stuck in swap. Restarting apache at that point clears the :swap space right out and memory is used properly again. Is there an actual performance hit here? Stuff that gets paged out is going to stay there until it's used. On a system that's not normally pressed for memory may well mean never. What you've described here isn't a problem. : :These seem to be short bursting peeks which i can;t get to in time to run :vmstat on. When i login i never see any paging or swapping going on maybe Then leave it running. $ while true do date >> logfile vmstat -c 3600 -w 1 | tee -a logfile done will put the date in your logfile every hour, and vmstat's output both to the screen and the logfile everysecond. Next time this happens, look at the logfile, and I'll bet you find you really are running out of memory. Figure out when it starts, and look at the apache logs, and you may be able to figure out what's causing it. It might be unusually heavy load, or memory hogging script, or something like that. It's also possible it's something other than the webserver, like a cronjob that does something ugly, or an interactive user. :2 blocked processes waiting to run seems the average under the b column :in vmstat. Another thing to note is cpu sky rockets when those burts :happen. How can a process go into swap really badly yet seem to not use :all available memory first. Disk I/O does not seem like a factor. What I Do you have any evidence that there's free memory when the box starts swapping? Free memory after the memory shortage has gone away is not evidence that there was memory available when it was swapping. The VM system is smarter than you are. Don't try and tune it before you know what's wrong. -- [EMAIL PROTECTED] Bipedalism is only a fad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problems with Squid on 4.4-RC
> > I really did not have time to investigate this but > the same problem occured with version 2.3 of Squid. The port > worked but the "off the shelf" version did not. The problem > was corrected for 2.3 and 2.4 but it seems it persists in the > source code available from the development site. > > I know I have no right to complain since I am too busy > to maintain any ports but I would like to encourage people > to submit corrections they make in the ports system to the > original maintainers. Hi, Ok. here's the problem in a nutshell. GCC is bad with optimisation levels above 0. Ok, here's the problem outside of the nutshell. There's some code in squid that triggers a gcc bug when using -O2 and sometimes with -O. There's some magic in the configure script to disable -Ox, but the gcc version in 4.4 (I think anything 4.3 and above really) wasn't put in the squid-2.4STABLE1 script. This is why when you run squid-2.4stable1 on your 4.4 box it barfs after one request - the DNS request is made, and the code pukes. The solution is just to use the port. All the package does is disable the -Ox when building. Oh, squid-2.4STABLE2 should know about the 4.4 GCC version. But I just suggest use the package or disable the optimisation yourself. :-) Adrian, not on -hackers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: the sum of n processes's virtual memory more than 4G?
craig wrote: > > I know every process in FreeBSD have 4G(3G user) space. But the > sum of n(n<4096?) processes seems to have n*4G virtual memory. > Is it possible? The physical max memory for i386 is 4G. Can I > just make a swap file more than 4G such like 6G, 8G or more? Yes. Each process runs in a completely seperate virtual address space. > I guess the sum of n processes's virtual memory can not be more > than 4G ,so the sum of physical memory and swap space cannot be > over 4G also.Can you confirm my view? A single process can not have more than 3G (default) of virtual memory, whether that memory is currently in swap, or has been moved to physical RAM, instead. > Another problem, is there any tool for instrumentation for > FreeBSD kernel? man systat man vmstat man top man netstat man sysctl -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
