Try this:
$ csh
% su
Password:
% stop $$
Suspended (signal)
%fg
At which point you will lose you login shell.
Prior to KSE one could switch between an su'ed shell and a
normal shell at will by using stop $$ and fg.
Is this breakage considered a bug or a feature?
To Unsubscribe: send mail
On Mon, Jul 15, 2002 at 04:00:29PM -0400, Garrett Wollman wrote:
On Mon, 15 Jul 2002 21:47:09 +0200, Robert Drehmel [EMAIL PROTECTED]
said:
You are right. However, I still consider it a bug. :-)
The standard says that the behavior is ``undefined''. That means that
you computer
.
It is not a bug.
No, you are quoting from the gawk(1) man page. The awk(1) man page makes
no such statement.
-gordon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
[Since you insisted on CC'ing me...]
On Tue, 16 Jul 2002 16:57:42 -0700 (PDT), Gordon Tetlow [EMAIL PROTECTED] said:
No, you are quoting from the gawk(1) man page. The awk(1) man page makes
no such statement.
The awk(1) manual page does not define the correct behavior of
gawk(1).
IEEE Std.
This is what I get:
one-true-awk:
Some Such DN
1000
1080
Some Other DN
1000
1405
gawk:
Some Such DN
Some Other DN
So, this seems to be a bug in the one-true-awk implementation. Any ideas
on how to fix this?
-gordon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
: 1000
uidNumber: 1080
dn: Some Other DN
gidNumber: 1000
uidNumber: 1405
This is what I get:
one-true-awk:
Some Such DN
1000
1080
Some Other DN
1000
1405
Ok.
gawk:
Some Such DN
Some Other DN
Oh.
So, this seems to be a bug in the one-true-awk implementation. Any
On Mon, 15 Jul 2002 09:06:36 -0700 (PDT), Gordon Tetlow [EMAIL PROTECTED] said:
Ah, okay, there is a distinct lack of documentation to that fact. I have
figured out that I can just set RS= and that does the same thing. I
suppose it would be helpful to have an awk book around. =)
The
On Sun, Jul 07, 2002 at 03:28:51PM -0700, Mike Makonnen wrote:
MALLOC(copy, struct plimit *, sizeof(struct plimit),
M_SUBPROC, M_WAITOK);
- bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct plimit));
+ bcopy(lim-pl_rlimit, copy-pl_rlimit, sizeof(struct rlimit));
needs to be copied
but is not in the array of rlimits).
or maybe:
bcopy((lim-pl_rlimit[0]), (copy-pl_rlimit[0]), sizeof(lim-pl_rlimit));
rather than just copying the first limit?
Same bug.
It might be better to just
bcopy the whole struct plimit and make a note that other fields need
Hello folks,
The limcopy() function bcopy()s a struct rlimit, but the len argument to
bcopy() is given as sizeof(struct plimit). This hasn't caused any
problems
so far because the destination address is the first member of struct
plimit
and all the other member of plimit are initialized
This is on beast.freebsd.org, running -current as of about 20 minutes
ago. I just rm'ed a .o file and did a make:
peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-6# rm yarrow.o
peter@beast[5:32pm]/usr/src/sys/alpha/compile/BEAST-7# make
cc -c -O -pipe -mcpu=ev56 -Wall -Wredundant-decls
I have seen this an dhoped that fixing some of the less scary ones would
fix it too..
^Z seems to occasionally kill the (or one of) process instead.
I have not figured it out..
Peter, did you see the mail I forwarded to you regarding the
condvar/msleep race?
I was hoping for a second
Hi all,
I just fixed a bug that has been hitting me everytime I do a sysctl -a
since inp locking was committed. I would like to commit it as soon as
possible, so I'd like it if someone could review it.
Thanks,
Maxime
Index: udp_usrreq.c
Maxime Henrion wrote:
Hi all,
I just fixed a bug that has been hitting me everytime I do a sysctl -a
since inp locking was committed.
BTW, this bug probably only arises when the security.bsd.see_other_uids
sysctl is set to 0, otherwise the cr_canseesocket() call always
succeeds. So
Can you try this fix instead? It's based on a similar patch Jonathan Lemon
sent to me for a similar spot in tcp_subr.c.
Index: udp_usrreq.c
===
RCS file: /home/ncvs/src/sys/netinet/udp_usrreq.c,v
retrieving revision 1.113
diff -u
Jeffrey Hsu wrote:
Can you try this fix instead? It's based on a similar patch Jonathan Lemon
sent to me for a similar spot in tcp_subr.c.
Well yes, this works too, since it produces the same code as with my
fix. But yours is more beautiful. :-)
Thanks,
Maxime
To Unsubscribe: send mail to
Maxime Henrion wrote:
I just fixed a bug that has been hitting me everytime I do a sysctl -a
since inp locking was committed. I would like to commit it as soon as
possible, so I'd like it if someone could review it.
Wow. Good catch.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED
is always executing (the Postfix master daemon).
I suspect an obscure VM system bug. postfix reload does not seem
to cure this condition. The problem goes away after postfix stop
then postfix start, which terminates the parent process.
This has happened to me only twice over the past year. My server
]
:
(repeat last 3 lines -- Ad nauseam)
I haven't seen anything on this topic, so I'd like to hear if
others are experiencing this as well and if this is a security
feature, a bug or misconfiguration.
I see this as well - on both -STABLE and -CURRENT. I do you have two
accounts you can try? I
feature, a bug or misconfiguration.
Yes, I see this sometimes too, even in -stable. I agree with your
conjecture -- it acts like there's an uninitialized variable that
sometimes starts out with an unworkable value.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle
On Mon, May 20, 2002 at 09:35:31AM +0100, Gavin Atkinson wrote:
I see this as well - on both -STABLE and -CURRENT. I do you have two
accounts you can try? I generally find that while the SRA login will
refuse one account, a different account can log in fine, without
reconnecting the telnet.
Marcel Moolenaar writes:
I see this as well - on both -STABLE and -CURRENT. I do you have two
accounts you can try? I generally find that while the SRA login will
refuse one account, a different account can log in fine, without
reconnecting the telnet.
Ok, now that I have confirmation,
I don't know much (anything) about the advisory locking code, but was
puzzled to see the following at the bottom of the flock() system call code
in kern_descrip.c:
if (uap-how LOCK_EX)
lf.l_type = F_WRLCK;
else if (uap-how LOCK_SH)
lf.l_type =
* Robert Watson [EMAIL PROTECTED] [020519 07:30] wrote:
I don't know much (anything) about the advisory locking code, but was
puzzled to see the following at the bottom of the flock() system call code
in kern_descrip.c:
if (uap-how LOCK_EX)
lf.l_type = F_WRLCK;
Robert Watson wrote:
I don't know much (anything) about the advisory locking code, but was
puzzled to see the following at the bottom of the flock() system call code
in kern_descrip.c:
[ ... ]
My reading of that is that the fp-f_flag field will be unconditionally
updated to include
and the only way around it is to
^C and re-telnet, which BTW occasionally fails as well...
I haven't seen anything on this topic, so I'd like to hear if
others are experiencing this as well and if this is a security
feature, a bug or misconfiguration.
Thanks,
--
Marcel Moolenaar USPA
I talked with klaus via IRC on #newcard on Friday. Turns out that the
'0' in question isn't in INTLINE, but rather part of the PIR table
listing which interrupts are valid. I have a patch in my local tree
that I hope to commit shortly.
I thought about fixing the powerof2 macro, but since it
Hi Folks.
I spent some time tracking down my CardBus problem and found the
following:
In /sys/i386/pci/pci_cfgreg.c:
In Function: static int pci_cfgintr_linked(struct PIR_entry *pe, int pin):
There you can find this code (my changes included):
/* link destination mapped to a
In message: Pine.GSO.4.44.0204121353110.3002-10@sunhalle19
Klaus Leibrandt [EMAIL PROTECTED] writes:
: Hi Folks.
:
: I spent some time tracking down my CardBus problem and found the
: following:
:
: In /sys/i386/pci/pci_cfgreg.c:
: In Function: static int
Hello Jeffrey,
Please try out this patch instead.
Index: uipc_mbuf.c
===
RCS file: /home/cvs/src/sys/kern/uipc_mbuf.c,v
retrieving revision 1.90
diff -u -6 -r1.90 uipc_mbuf.c
--- uipc_mbuf.c 5 Feb 2002 02:00:53
Maksim Yevmenkin wrote:
it does _exactly_ the same thing as patch i sent. the idea is
to set n-m_len to zero. in this particular part of the code
n is not modified. only n-m_next. so i do not see any
difference except your patch is 4 lines :)
Yours is less efficient.
-- Terry
To
System Administrator wrote:
Your message
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Bug in m_split() ?
Sent:Wed, 10 Apr 2002 09:23:16 -0700
did not reach the following recipient(s):
[EMAIL PROTECTED] on Wed, 10 Apr 2002 09:23:21 -0700
The e-mail system
Hi,
kern.pre.mk contains
NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
PROFILE_C= ${CC} -c ${CFLAGS} ${WERROR} ${.IMPSRC}
NORMAL_C_NOWERROR= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC}
shouldn't this be
NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${.IMPSRC}
PROFILE_C= ${CC} -c
Alexander Leidinger wrote:
Hi,
kern.pre.mk contains
NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
PROFILE_C= ${CC} -c ${CFLAGS} ${WERROR} ${.IMPSRC}
NORMAL_C_NOWERROR= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC}
shouldn't this be
NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR}
On Tue, 2 Apr 2002, Alexander Leidinger wrote:
Hi,
kern.pre.mk contains
NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC}
PROFILE_C= ${CC} -c ${CFLAGS} ${WERROR} ${.IMPSRC}
NORMAL_C_NOWERROR= ${CC} -c ${CFLAGS} ${PROF} ${.IMPSRC}
shouldn't this be
NORMAL_C= ${CC} -c
Hello, Martin Blapp!
On Mon, Mar 04, 2002 at 01:10:58AM +0100, you wrote:
It looks like our modified FreeBSD GCC breaks the STLport tests,
as it breaks OpenOffice too.
If one uses a normal unmodified stock gcc version (gcc 2.95.2 or
2.95.3), and compiles it on STABLE or CURRENT, the
Hi,
Not help, but a question:
If openoffice compiles with ports' version of gcc?
And if it runs compiled this way?
unfortunatly not. The build segfaults in a different way. I'll upgrade the port
to the latedt build tomorrow. Let's see if it builds now properly with
gcc3.1
Martin
To
Hello, Martin Blapp!
On Sat, Mar 30, 2002 at 06:38:20PM +0100, you wrote:
If openoffice compiles with ports' version of gcc?
And if it runs compiled this way?
unfortunatly not. The build segfaults in a different way. I'll upgrade the port
to the latedt build tomorrow. Let's see if it
With gcc3.1 on -CURRENT, or with gcc3.1 on -STABLE?
Both :)
martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Martin Blapp wrote:
Not help, but a question:
If openoffice compiles with ports' version of gcc?
And if it runs compiled this way?
unfortunatly not. The build segfaults in a different way. I'll upgrade the port
to the latedt build tomorrow. Let's see if it builds now properly with
free bug
From: Poul-Henning Kamp [EMAIL PROTECTED]
Date: Mon, 11 Mar 2002 23:13:57 +0100
Message-ID: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
As author of our malloc(3) it is my opinion that we are not vulnerable to
this (kind of) bug.
Most mallocs keep their housekeeping data right next
On Fri, 1 Feb 2002, Peter Wemm wrote:
- AMD write cache allocation due to speculative writes being cancelled and
then written back later vs no cache snooping on AGP regions. I'm somewhat
perplexed about this issue, there's lots of conflicting info going around,
a good deal of it which
Narvi wrote:
Speculative writes can only happen to pages in the TLB (so you don't get
speculative TLB misses and replacements), not having a large amount of 4M
pages around in the TLB means that addresses covered by these can't
possibly be involved in speculative writes.
I personaly
On Mon, 4 Feb 2002, Terry Lambert wrote:
Narvi wrote:
Speculative writes can only happen to pages in the TLB (so you don't get
speculative TLB misses and replacements), not having a large amount of 4M
pages around in the TLB means that addresses covered by these can't
possibly be
Narvi wrote:
I wasn't aware that I was contradicting Peter 8-)
Sorry; looked like it to me... 8-).
It may even well be possible to get different results with aligned vs.
misaligned reads and writes, or a proper mix thereof. It may be possible
to build a model to track down the what is
generated inlines. They wanted to
charge me to file a bug report, too, so I demanded that
they agree to send me a T-shirt before I would tell them
the fix. As far as I know, they still have the bug.
Microsoft also charged me to report a bug in the removable
media driver in Windows 95/98 (you can't
and 4K pages and TLB flushing
(potentially cross platform issue due to boot time quirks).. I think we have
a workaround for this in our code already, but I have a better complete fix
for it in a pending change that I'm working on.
- AMD invlpg vs 4MB page bug (AMD bug). If you invlpg using an address
Peter Wemm wrote:
I'm a little confused as to which bugs are which that we're talking
about now. Which is the one that you're trying to sell the info for?
I'm not really trying to sell the fix; it's that I'm not
willing to give it away when it's no benefit to do so; I'd
need a bribe. Kind of
On Thu, 31 Jan 2002, Jason Evans wrote:
On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote:
Linux can be fixed, but the useless writes of the existing Athlons from
the very fast cache to the relatively very slow memory cannot. And all
Athlon users may well pay this penalty
into an aperture marked cacheable and in a 4M page;
it's a coding problem with the use of 4M pages, when memory
in them is allocated to AGP.
This still doesn't get around the other bug, which happens
if you use 4M pages certain obviously useful ways, without
waving a dead chicken over certain
is not the
real problem. Just it has revealed the AMD issue.
It might be argued that there should be some cache-coherence protocol
between the CPU and the AGP device. Not knowing how AGP is specified I
don't know if this interaction between the CPU and AGP is a bug or just
working as specified. I
AGP is specified I
don't know if this interaction between the CPU and AGP is a bug or just
working as specified. I suspect it is the latter though.
AGP does not require cache to snoop AGP accesses to memory, but it
perfectly allows implementations to ensure such coherency. As a result,
AGP
.
This is what Bruce and Peter suggested; Peter said that he was
working on a rewrite of the pmap code and would look in that
area.
Not knowing how AGP is specified I don't know if this interaction
between the CPU and AGP is a bug or just working as specified. I
suspect it is the latter though
Kenneth Culver wrote:
Actually FreeBSD does make use of them, but in a way that doesn't cause a
problem.
There's actually a seperate TLB bug, but FreeBSD doesn't
trigger that one, either (Linux can tickle it, when there
are certain specific circumstances met).
$10,000, and I'll tell you how
On Wed, 23 Jan 2002, Bruce Evans wrote:
On Sun, 20 Jan 2002, k Macy wrote:
Should I file a PR to track this or is that overkill?
Yes, it would be overkill. Remind me if it's not fixed in a week or two.
I tested and committed the fix.
Please report any other profiling bugs for SMP. I'm
There's actually a seperate TLB bug, but FreeBSD doesn't
trigger that one, either (Linux can tickle it, when there
are certain specific circumstances met).
Well, I think I know what you're talking about, linux allocates agpgart
memory without setting a non-cacheable bit, and then the agp card
Message-
From: Kenneth Culver [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 10:42 AM
To: Terry Lambert
Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]';
'[EMAIL PROTECTED]'
Subject: Re: AMD AGP Bug
There's actually a seperate TLB bug, but FreeBSD doesn't
trigger
PROTECTED]'
Subject: Re: AMD AGP Bug
There's actually a seperate TLB bug, but FreeBSD doesn't
trigger that one, either (Linux can tickle it, when there
are certain specific circumstances met).
Well, I think I know what you're talking about, linux
allocates agpgart
memory without
strange issues like the AMD AGP bug we are talking
about could turn this into a real problem.
Linux can be fixed, but the useless writes of the existing Athlons from
the very fast cache to the relatively very slow memory cannot. And all
Athlon users may well pay this penalty under any OS... unless
Kenneth Culver wrote:
There's actually a seperate TLB bug, but FreeBSD doesn't
trigger that one, either (Linux can tickle it, when there
are certain specific circumstances met).
Well, I think I know what you're talking about, linux allocates agpgart
memory without setting a non-cacheable
a coding problem with the use of 4M pages, when memory
in them is allocated to AGP.
This still doesn't get around the other bug, which happens
if you use 4M pages certain obviously useful ways, without
waving a dead chicken over certain things. 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL
I'm thinking you may have misunderstood, the people at amd themselves said
this wasn't an amd bug... why would you write from cache to memory, I
think it's the other way around, stuff getting written to cache from
memory... (being retrieved by the cpu) I'll have to read the article again
On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote:
Linux can be fixed, but the useless writes of the existing Athlons from
the very fast cache to the relatively very slow memory cannot. And all
Athlon users may well pay this penalty under any OS... unless we want to
disable
I was under the impression that they were writing into the cache not out
of it... I really need to read that article again :-D
Ken
On Thu, 31 Jan 2002, Jason Evans wrote:
On Wed, Jan 30, 2002 at 11:14:48PM +0100, Gérard Roudier wrote:
Linux can be fixed, but the useless writes of the
Terry Lambert wrote:
Cameron, Frank wrote:
From what was posted on the linux-kernel list the problem is the OS
doing the wrong thing not the hardware. I originally asked the
question (albeit not worded as clearly as I should have) because if
Microsoft and Linux programmers made the same
Cc: David Malone; Cameron, Frank; '[EMAIL PROTECTED]';
'[EMAIL PROTECTED]'
Subject: Re: AMD AGP Bug
There's actually a seperate TLB bug, but FreeBSD doesn't
trigger that one, either (Linux can tickle it, when there
are certain specific circumstances met).
Well, I think
Peter Wemm wrote:
We need to use the PAT cpu_features feature. This gives us 8 page attribute
modes instead of simple no-cache / writethrough flags. We can (and must)
control more carefully the speculative hardware prefetch, for example.
I've been thinking about this with the pmap revamp
Peter Wemm wrote:
No. FreeBSD does not make active use of 4M pages for anything
other than the initial kernel text and data, which is obvious,
if you look at /sys/i386/machdep.c.
Actually, it is obvious if you actually do look at the pmap.c that we *do*
use 4MB pages for device
On Thu, Jan 31, 2002 at 07:22:25PM -0800, Terry Lambert wrote:
Peter Wemm wrote:
We need to use the PAT cpu_features feature. This gives us 8 page attribute
modes instead of simple no-cache / writethrough flags. We can (and must)
control more carefully the speculative hardware prefetch,
Steve Kargl wrote:
This sounds cool.
Do you have references to the page attribute stuff? The
books I have here don't discuss it; the only thing I see
are 3 bits (9,10,11) that are available in the PDE and
PTE?
Well, twice in this thread you've offered info for
$1. I'm sure
Has this issue been addressed in FreeBSD:
http://www.geocrawler.com/lists/3/Linux/35/175/7626960/
http://slashdot.org/article.pl?sid=02/01/24/1910227mode=thread
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Wed, Jan 30, 2002 at 12:13:07PM -0500, Cameron, Frank wrote:
Has this issue been addressed in FreeBSD:
http://www.geocrawler.com/lists/3/Linux/35/175/7626960/
http://slashdot.org/article.pl?sid=02/01/24/1910227mode=thread
This is believed not to have any impact on FreeBSD because FreeBSD
You should check the archives of the FreeBSD mailing lists before sending
a message to 4 of the lists. This quiestion has been answered several
times on the FreeBSD lists. The answer is that this isn't even really an
AMD AGP bug, it's a bug in the way linux handles mapping it's AGP memory
Actually FreeBSD does make use of them, but in a way that doesn't cause a
problem.
Ken
On Wed, 30 Jan 2002, David Malone wrote:
On Wed, Jan 30, 2002 at 12:13:07PM -0500, Cameron, Frank wrote:
Has this issue been addressed in FreeBSD:
On Sun, 20 Jan 2002, k Macy wrote:
Should I file a PR to track this or is that overkill?
Yes, it would be overkill. Remind me if it's not fixed in a week or two.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Raman Ng wrote:
I don't know what mailing list this mail should be
posted to, sorry if it is posted to the wrong mailing
list.
Recently I found Linux 2.4 kernel is affected by the
bug of extended paging in AMD Athlon through the
following link. I don't know if FreeBSD is also
affected
I am well aware of this bug.
It does not affect FreeBSD, which only uses 4M pages
for
the first 4M of the kernel itself.
I've worked on code that enables 4M pages on other
memory
used in FreeBSD, that had this problem, but only if
you
were really stupid in your allocation mechanism
, it is
certainly broken if the
atomic functions that it calls are not inlined (then
the functions will
call MCOUNT_ENTER() on entry). I think this only
happens if mcount.c
is compiled with -O0. This bug is missing in
RELENG_4 too.
%%%
Index: profile.h
k Macy wrote:
It turns that this problem is specific to AIO in
-CURRENT. I wrote a simple program that uses
the three different completion mechanisms (polling
with aio_error, polling with kevent, and using SIGIO)
to fill up a file by writing 8kb at a time to the
file and then reading 8kb
Thanks for working on this. I was going to try running
a profiled kernel on -CURRENT and -STABLE to see what
the difference was in time distribution. On -STABLE
it built without a hitch. However, on -CURRENT I got
the following even after doing a make clean:
../../../libkern/mcount.c: In
if mcount.c
is compiled with -O0. This bug is missing in RELENG_4 too.
%%%
Index: profile.h
===
RCS file: /home/ncvs/src/sys/i386/include/profile.h,v
retrieving revision 1.25
diff -u -2 -r1.25 profile.h
--- profile.h 30 Oct 2001 15
It turns that this problem is specific to AIO in
-CURRENT. I wrote a simple program that uses
the three different completion mechanisms (polling
with aio_error, polling with kevent, and using SIGIO)
to fill up a file by writing 8kb at a time to the
file and then reading 8kb at a time from the
Really easy to reproduce.
ls -lR /proc
vmstat -m | fgrep vfscache
ls -lR /proc
vmstat -m | fgrep vfscache
ls -lR /proc
vmstat -m | fgrep vfscache
The pseudofs code is using the wrong VOP descriptor, but I'll let DES
fix it when he gets back. In the mean time
Near the end of fork1():
/*
* If RFSTOPPED not requested, make child runnable and add to
* run queue.
*/
microtime((p2-p_stats-p_start));
p2-p_acflag = AFORK;
if ((flags RFSTOPPED) == 0) {
mtx_lock_spin(sched_lock);
* Julian Elischer [EMAIL PROTECTED] [011218 18:20] wrote:
now, what is to say that the process has not exitted by this stage, and
been reeped by init (on SMP)
particularly since between the two is:
/*
* Preserve synchronization semantics of vfork. If waiting for
On 19-Dec-01 Julian Elischer wrote:
Near the end of fork1():
/*
* If RFSTOPPED not requested, make child runnable and add to
* run queue.
*/
microtime((p2-p_stats-p_start));
p2-p_acflag = AFORK;
if ((flags RFSTOPPED) == 0) {
On 19-Dec-01 John Baldwin wrote:
It may be that due to some semantics of teh fork calls
you cannot have P_PPWAIT and a process queued to run on the other
processor while reparented to init(1) but I can't see it..
the result would be that the return value MIGHT be teh pid
of a totally
On 19-Dec-01 Alfred Perlstein wrote:
* Julian Elischer [EMAIL PROTECTED] [011218 18:20] wrote:
now, what is to say that the process has not exitted by this stage, and
been reeped by init (on SMP)
particularly since between the two is:
/*
* Preserve synchronization
* John Baldwin [EMAIL PROTECTED] [011218 18:41] wrote:
Actually, it's a bit worse than that. The parent process will sleep on itself
waiting to be woken up, but when the child exits, it will wake up init
(p-p_pptr) not the waiting process, so if you do a rfork(..., RFNOWAIT |
RFPPWAIT);
for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack. You also have a bug in the
way you changed the check for cancellation flags.
There only clean way to fix this is to add a return frame
to the interrupted context so that it can check
on the scheduler
stack, not the threads stack.
That makes sense, but why?
You also have a bug in the
way you changed the check for cancellation flags.
What?
There only clean way to fix this is to add a return frame
to the interrupted context so that it can check
for cancellation when
ctxtype == CTX_UC because you are running on the scheduler
stack, not the threads stack.
That makes sense, but why?
You also have a bug in the
way you changed the check for cancellation flags.
What?
There only clean way to fix
.
You also have a bug in the
way you changed the check for cancellation flags.
What?
When a thread is at a cancellation point, you want to let the
cancellable routine handle the cancel. The check as coded before
avoided calling pthread_testcancel() when
* Daniel Eischen [EMAIL PROTECTED] [011204 12:32] wrote:
Alfred Perlstein wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal interrupt
(ctxtype != CTX_UC).
Alfred Perlstein wrote:
* Daniel Eischen [EMAIL PROTECTED] [011204 12:32] wrote:
Alfred Perlstein wrote:
* Dan Eischen [EMAIL PROTECTED] [011204 06:26] wrote:
There are already cancellation tests when resuming threads
whose contexts are not saved as a result of a signal
* Daniel Eischen [EMAIL PROTECTED] [011130 16:17] wrote:
On Fri, 30 Nov 2001, Louis-Philippe Gagnon wrote:
If at first you don't succeed...
I've encountered a problem using pthread_cancel, pthread_join and
pthread_setcanceltype, I'm hoping someone can shed some light.
(in a
* Louis-Philippe Gagnon [EMAIL PROTECTED] [011130 15:57] wrote:
If at first you don't succeed...
I've encountered a problem using pthread_cancel, pthread_join and
pthread_setcanceltype, I'm hoping someone can shed some light.
Provide me with minimal sample code and a makefile and i should
the questions are
-am I doing something wrong or misinterpreting the man pages?
-if not, is this a known bug?
-if so, is there a workaround (or is it already fixed)?
-if not, can someone investigate? (I once had a look at the libc_r code
and ran away screaming)
If this turns out to be a bug in libc_r
to be cancelled at any time)
see the end of this message for my test program
So the questions are
-am I doing something wrong or misinterpreting the man pages?
No, not really.
-if not, is this a known bug?
Or feature?
-if so, is there a workaround (or is it already fixed)?
Not fixed
are
-am I doing something wrong or misinterpreting the man pages?
-if not, is this a known bug?
-if so, is there a workaround (or is it already fixed)?
-if not, can someone investigate? (I once had a look at the libc_r code
and ran away screaming)
If this turns out to be a bug in libc_r
901 - 1000 of 1405 matches
Mail list logo
