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
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
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
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
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
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
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
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
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
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
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:
>
> 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:
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
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
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 "
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
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
< 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
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
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
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
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
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
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
<
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]
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
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
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
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
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
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 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
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).
> 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 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
> 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
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,
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
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
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
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
--
>>> Rebuilding the temporary build tree
--
>>> stage 1: bootstrap tools
--
>>> stage 2: cleaning up the object tree
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
* 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
44 matches
Mail list logo