* David Xu <[EMAIL PROTECTED]> [020715 22:31] wrote:
> I found a race condition in kern_descrip.c, the race is in function falloc(),
> it opens a race window at line 1147:
You're right, however I'd appreciate it if you'd look deeper into the
possiblity of races in this code before committing this
I found a race condition in kern_descrip.c, the race is in function falloc(),
it opens a race window at line 1147:
FILEDESC_UNLOCK(p->p_fd);
sx_xlock(&filelist_lock);
FILEDESC_LOCK(p->p_fd);
fix:
--- kern_descrip.c Tue Jul 16 12:29:44 2002
+++ kern_des
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
Third one:
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is
On Tue, 16 Jul 2002, David Taylor wrote:
Bah, ignore me, it appears you've already admitted your post was rather
less than clear :)
--
David Taylor
[EMAIL PROTECTED]
"The future just ain't what it used to be"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
On Mon, 15 Jul 2002, Terry Lambert wrote:
> Thomas Moestl wrote:
> > > He's making the valid point that for:
> > >
> > > struct foo *fee;
> > >
> > > It's possible that:
> > >
> > > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
> >
> > No, I do not. In fact, the opposi
And another one comes along:
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the con
Richard Tobin wrote:
> It is not a valid point that it's possible that
>
> sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> because it isn't possible. It must be the case that
>
> sizeof(struct foo) == (((char *)&fee[1]) - ((char *)&fee[0]))
>
> If that's what you meant,
> If everyone could read the text past my example of bad math, so
> that they could know it was an intentional example of bad math,
> live would be beautiful. 8-).
I did read past it, and I just read it again, and I can't make it come
out any way other than it did the first time.
You said:
> H
On Mon, Jul 15, 2002 at 06:00:32PM -0400, Alexander Kabaev wrote:
> Bruce,
>
> I am reliably get these messages while using gdb on user processes. This
> started long before KSEIII.
Right, I forgot to add that I was also running this program under gdb.
I'm using the most recent -current right no
> Maybe. I got a few of these for my original ast() changes an instant
> after I committed them (long before KSEIII), but haven't been able to
> duplicate the problem (perhaps because they only occurred for SMP and
> I rarely run SMP). I use the following change which prints more info
> and fixe
On Tue, Jul 16, 2002 at 07:04:46AM +1000, Bruce Evans wrote:
> Maybe. I got a few of these for my original ast() changes an instant
> after I committed them (long before KSEIII), but haven't been able to
> duplicate the problem (perhaps because they only occurred for SMP and
> I rarely run SMP).
Peter Wemm writes:
> Eww! Care to confirm that the following works? I was going to just commit
> it since it is pretty obvious, but a brief sanity check would probably
> be an idea. (beware, xterm cut/paste whitespace damage).
>
> ddb runs with interrupts disabled and the other cpus halt
Richard Tobin wrote:
> Er, no, that's not right. Otherwise
[ ... ]
If everyone could read the text past my example of bad math, so
that they could know it was an intentional example of bad math,
live would be beautiful. 8-).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsub
Peter Edwards wrote:
> > He's making the valid point that for:
> >
> > struct foo *fee;
> >
> > It's possible that:
> >
> > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> Wouldn't that mean
>
> .. struct X *xarr = malloc(sizeof (struct X) * arrayLen);
>
> woul
Eww! Care to confirm that the following works? I was going to just commit
it since it is pretty obvious, but a brief sanity check would probably
be an idea. (beware, xterm cut/paste whitespace damage).
ddb runs with interrupts disabled and the other cpus halted. We could not
get the 'ack' fro
Thomas Moestl wrote:
> > He's making the valid point that for:
> >
> > struct foo *fee;
> >
> > It's possible that:
> >
> > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> No, I do not. In fact, the opposite:
>
> sizeof(struct foo) = (((char *)&fee[1]) - ((c
On Mon, 15 Jul 2002, Bill Huey wrote:
> I get a billion of these:
>
> failed to set signal flags proprly for ast()
> failed to set signal flags proprly for ast()
> failed to set signal flags proprly for ast()
> failed to set signal flags proprly for ast()
> failed to
I was attempting to set a breakpoint; upon continuation, the kernel
panic'ed with:
gm0: mem 0xfb00-0xfbff irq 11 at
device 1.0 on pci1
Debugger("here") # breakpoint I put in my module's load path
Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0
db> break generic_bzero
db> c
<
said:
> You are right. However, I still consider it a bug. :-)
The standard says that the behavior is ``undefined''. That means that
you computer is allowed to turn into a frog. Actually doing something
useful is also permitted.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
Hello Brandon,
On Mon, Jul 15, 2002 at 02:53:59PM -0400, Brandon S. Allbery KF8NH wrote:
> On Mon, 2002-07-15 at 11:37, Robert Drehmel wrote:
> > To me, this seems like a bug in 'gawk'. The AWK language uses
> > only the first character in RS as the record separator, to my
> > knowledge.
>
> H
Hello,
I get a billion of these:
failed to set signal flags proprly for ast()
failed to set signal flags proprly for ast()
failed to set signal flags proprly for ast()
failed to set signal flags proprly for ast()
failed to set signal flags proprly for as
On Mon, 2002-07-15 at 11:37, Robert Drehmel wrote:
> To me, this seems like a bug in 'gawk'. The AWK language uses
> only the first character in RS as the record separator, to my
> knowledge.
Hm, I thought that was a gawk extension.
--
brandon s. allbery [linux][solaris][japh][freebsd]
[EMAI
Hi,
got another panic in the line of panicstr: bremfree:
bp 0xc77cc8a0 not locked
GNU gdb 5.2 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain co
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
Thomas Moestl <[EMAIL PROTECTED]> writes:
> Oh, right, that's related: the kernel checks for a minimum size of the
> passed data on two occasions, first in sooptcopyin(), and then again
> in check_ipfw_struct().
> It the size to be at least sizeof(struct ip_fw), however for
> structures containing
< 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 Standard is clear:
# The first character of the string value of RS shall
On Mon, 15 Jul 2002, Robert Drehmel wrote:
> > So, this seems to be a bug in the one-true-awk implementation. Any ideas
> > on how to fix this?
>
> To me, this seems like a bug in 'gawk'. The AWK language uses
> only the first character in RS as the record separator, to my
> knowledge.
Ah, ok
ok, convincing explaination, thanks!
I will review the code and try to implement a proper fix,
not the workaround that I put in.
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hi.
On Wed, Jul 03, 2002 at 09:36:24PM +0200, Rasmus Skaarup wrote:
>
> I'm also suddenly having a panics - every 5 minutes actually, since my
> latest cvsup a few hours ago. They seem to be related to some ufs
> and ffs calls..
>
> I'm not able to read my core dumps for some reason (gdb says "
On Mon, Jul 15, 2002 at 08:20:58AM -0700, Gordon Tetlow wrote:
> I was parsing ldif format with awk (formerly gawk) and found a buglet in
> awk with the following script:
>
> BEGIN {
> RS="\n\n";
> FS="(: |\n)";
> }
>
> { print $2; }
>
> Fed the following output:
>
> dn: Some Such
I was parsing ldif format with awk (formerly gawk) and found a buglet in
awk with the following script:
BEGIN {
RS="\n\n";
FS="(: |\n)";
}
{ print $2; }
Fed the following output:
dn: Some Such DN
gidNumber: 1000
uidNumber: 1080
dn: Some Other DN
gidNumber: 1000
uidNumber: 140
> struct foo *fee;
>
> It's possible that:
>
> sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
>
> because of end-padding, which is not accounted for in arrays,
Er, no, that's not right. Otherwise
fee = malloc(n * sizeof(struct foo))
wouldn't work.
C89 says:
Dans votre courrier du 15 Jul 14:40 vous ecrivez :
>
>Hi,
>
>> If you are interested, I have make a full check of NFS/RPC related code in
>> FreeBSD current (June 24), and I have some mods to complete the port of
>> kernel NFS and RPC applcations to TI-RPC and/or IPv6
>> The modified files are:
>
Hi,
> He's making the valid point that for:
>
> struct foo *fee;
>
> It's possible that:
>
> sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0]))
Wouldn't that mean
.. struct X *xarr = malloc(sizeof (struct X) * arrayLen);
wouldn't produce a useable array of struct X o
On Mon, 2002/07/15 at 04:24:33 -0700, Terry Lambert wrote:
> Luigi Rizzo wrote:
> > sorry but all this just does not make sense to me.
> >
> > sizeof(foo) should give the same result irrespective of
> > where you use it.
> >
> > Perhaps the best thing would be to put a
> >
> > printf("s
On Mon, 2002/07/15 at 04:00:08 -0700, Luigi Rizzo wrote:
> sorry but all this just does not make sense to me.
>
> sizeof(foo) should give the same result irrespective of
> where you use it.
OK, let me rephrase it: as I explained before, struct ip_fw has padding
after 'cmd' (the last member) to e
Hi,
> If you are interested, I have make a full check of NFS/RPC related code in
> FreeBSD current (June 24), and I have some mods to complete the port of
> kernel NFS and RPC applcations to TI-RPC and/or IPv6
> The modified files are:
Of course we are interested ! I knew that many servers did
In your mail dated Jul 14, 11:14 you wrote
>I'm still upset that we don't have tirpc99, when do you plan on porting
>that over?
If you are interested, I have make a full check of NFS/RPC related code in
FreeBSD current (June 24), and I have some mods to complete the port of
kernel NFS and RPC ap
Luigi Rizzo wrote:
> sorry but all this just does not make sense to me.
>
> sizeof(foo) should give the same result irrespective of
> where you use it.
>
> Perhaps the best thing would be to put a
>
> printf("struct ip_fw has size %d\n", sizeof(struct ip_fw));
>
> both in ipfw2.c and s
sorry but all this just does not make sense to me.
sizeof(foo) should give the same result irrespective of
where you use it.
Perhaps the best thing would be to put a
printf("struct ip_fw has size %d\n", sizeof(struct ip_fw));
both in ipfw2.c and somewhere in ip_fw2.c and see if there i
On Sun, 2002/07/14 at 23:08:21 -0400, Mike Barcroft wrote:
> Thomas Moestl <[EMAIL PROTECTED]> writes:
> > (Disclaimer: my solution below is untested, so it may all be bogus)
>
> As request, here are the test results.
>
> Most rules work, except my final one:
> %%%
> bowie# ipfw add allow all fr
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
Hi!
Of late I'm getting a signal 10 in makeinfo for numerous ports (eg.
gcc31, semantic) and other non-port sources. And IIRC have been able to
build the gcc31 port six weeks ago without any problems.
world and kernel are of yesterday.
Marc
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
44 matches
Mail list logo
