ATTENTION, Medium not
:present
:
:Bus scan is probably happening before the device is fully powered up.
:One problem I noticed was that umass_cam_rescan() doesn't fill out the ccb
:properly, leaving timeout as 0 for instance. This probably won't hurt but
:I'm not sure. Anoth
On Thu, Dec 19, 2002 at 04:25:40PM -0800, Nate Lawson wrote:
> if (csio->ccb_h.flags & CAM_CDB_POINTER) {
> cmd = (unsigned char *) csio->cdb_io.cdb_ptr;
> } else {
> cmd = (unsigned char *) &csio->cdb_io.cdb_bytes;
>
up.
One problem I noticed was that umass_cam_rescan() doesn't fill out the ccb
properly, leaving timeout as 0 for instance. This probably won't hurt but
I'm not sure. Another bug available from cursory overview is:
if (csio->ccb_h.flags & CAM_CDB_P
On Thu, Dec 19, 2002 at 03:24:28PM -0800, Nate Lawson wrote:
> On Thu, 19 Dec 2002, Bernd Walter wrote:
> > On Thu, Dec 19, 2002 at 09:06:19AM -0800, Matthew Dillon wrote:
> > > The panic described in 46176 has happened to me on -current. On
> > > -stable I have managed (very easily) to ge
On Thu, 19 Dec 2002, Bernd Walter wrote:
> On Thu, Dec 19, 2002 at 09:06:19AM -0800, Matthew Dillon wrote:
> > The panic described in 46176 has happened to me on -current. On
> > -stable I have managed (very easily) to get the CAM layer vs UMASS
> > layer into a confused state where th
T_UNIT_READY returns TRUE.
Ok, so here is the patch. I need help with two things.
>>> First, are my RA_NO_CLEAR_UA bug fixes correct?
>>> Second, does anyone have any ideas on how we can
make CAM/UMASS friendlier to devices which take
longer to get themselves
:>
:> Eh? For ATAPI and UFM devices we never send a 6 byte command to the
:> device that can fail, only 10 byte commands.
:
:I believed this was a SCSI over bulk only device.
:
:--
:B.Walter COSMO-Project http://www.cosmo-project.de
:[EMAIL PROTECTED] Usergroup
On Thu, Dec 19, 2002 at 12:49:16PM -0500, John Baldwin wrote:
>
> On 19-Dec-2002 Bernd Walter wrote:
> > On Thu, Dec 19, 2002 at 12:24:09PM -0500, John Baldwin wrote:
> >> On 19-Dec-2002 Matthew Dillon wrote:
> >> > It took a hellofalong time pulling my hair out trying to figure out
> >> >
On 19-Dec-2002 Bernd Walter wrote:
> On Thu, Dec 19, 2002 at 12:24:09PM -0500, John Baldwin wrote:
>>
>> On 19-Dec-2002 Matthew Dillon wrote:
>> > It took a hellofalong time pulling my hair out trying to figure out
>> > why the Sony disk-on-key I just bought didn't work.
>> >
>> > Fi
:> > didn't solve the problem.
:>
:> You don't need the 6-byte quirk entries anymore. The umass(4) driver
:> automatically handles 6-byte commands (converting them to 10-byte commands)
:> and has done so for a while now. You should at least try removing the
:> 6 byte quirk for now.
:
:I tou
On Thu, Dec 19, 2002 at 12:24:09PM -0500, John Baldwin wrote:
>
> On 19-Dec-2002 Matthew Dillon wrote:
> > It took a hellofalong time pulling my hair out trying to figure out
> > why the Sony disk-on-key I just bought didn't work.
> >
> > First I added a Quirk entry for the standard 6
On Thu, Dec 19, 2002 at 09:06:19AM -0800, Matthew Dillon wrote:
>
> :
> :On Thu, Dec 19, 2002 at 12:08:27PM +0100, Frode Nordahl wrote:
> :> Hey, Matt
> :>
> :> While you're at it, could you have a look at PR kern/46176 ? =)
> :>
> :> At least would you tell me if you have the same problem with
On 19-Dec-2002 Matthew Dillon wrote:
> It took a hellofalong time pulling my hair out trying to figure out
> why the Sony disk-on-key I just bought didn't work.
>
> First I added a Quirk entry for the standard 6-byte problem, but it
> didn't solve the problem.
You don't need the
:
:> Note that my other UMASS device, a compact flash reader, has always
:> worked fine with just the Quirk entry. I really need a USB expert to
:> tell me what is going on :-)
:
:The problem is that an umass bulk only umass device is allowed to stall the
:comunication pipe on an inv
:
:On Thu, Dec 19, 2002 at 12:08:27PM +0100, Frode Nordahl wrote:
:> Hey, Matt
:>
:> While you're at it, could you have a look at PR kern/46176 ? =)
:>
:> At least would you tell me if you have the same problem with your
:> device(s)
:
:The umass cam interaction is questionable.
:I've seen lots
On Thu, Dec 19, 2002 at 12:08:27PM +0100, Frode Nordahl wrote:
> Hey, Matt
>
> While you're at it, could you have a look at PR kern/46176 ? =)
>
> At least would you tell me if you have the same problem with your
> device(s)
The umass cam interaction is questionable.
I've seen lots of problems c
On Thu, Dec 19, 2002 at 02:32:23AM -0800, Matthew Dillon wrote:
> It took a hellofalong time pulling my hair out trying to figure out
> why the Sony disk-on-key I just bought didn't work.
>
> First I added a Quirk entry for the standard 6-byte problem, but it
> didn't solve the pro
Hey, Matt
While you're at it, could you have a look at PR kern/46176 ? =)
At least would you tell me if you have the same problem with your
device(s)
On Thu, 2002-12-19 at 11:32, Matthew Dillon wrote:
> It took a hellofalong time pulling my hair out trying to figure out
> why the Sony di
It took a hellofalong time pulling my hair out trying to figure out
why the Sony disk-on-key I just bought didn't work.
First I added a Quirk entry for the standard 6-byte problem, but it
didn't solve the problem.
Finally, after slogging through an insane amount of debugging (
Marcus Reid <[EMAIL PROTECTED]> found a pair of bad bugs in the
GBDE code which could result in corrupt data under some circumstances.
The two separate bug was in the mapping code which decides where
to put the encrypted sectors on the device.
One bug affected only certain mult
tunefs(8) appears to do a mount/MNT_RELOAD of an fs even when it doesn't
perform any action. To reproduce:
mount -r /usr
tunefs -n enable /usr
[repeat]
Is this a bug?
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sat, 14 Dec 2002, Ruslan Ermilov wrote:
> On Sat, Dec 14, 2002 at 09:02:40PM +1100, Bruce Evans wrote:
> > For ANSI C, the result of the subtraction only depends on the width
> > of unsigned char. If unsigned char has the same width as int, then
> > the result is UINT_MAX; otherwise the result
On Sat, Dec 14, 2002 at 09:02:40PM +1100, Bruce Evans wrote:
> On Fri, 13 Dec 2002, Ruslan Ermilov wrote:
>
> > On Fri, Dec 13, 2002 at 04:41:06PM +0300, Andrey A. Chernov wrote:
> > > On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote:
> > > > Pardon my ignorance here, but the following
On Fri, 13 Dec 2002, Ruslan Ermilov wrote:
> On Fri, Dec 13, 2002 at 04:41:06PM +0300, Andrey A. Chernov wrote:
> > On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote:
> > > Pardon my ignorance here, but the following fragment
> > > returns -1, doesn't it?
> > >
> > > #include
> > > voi
On Fri, Dec 13, 2002 at 17:09:42 +0200, Ruslan Ermilov wrote:
> :
> : * Integer types `unsigned short' and `unsigned char' promote to
> : `unsigned int'.
>
> With -traditional, the code I quoted still produces -1.
Probably because of machine-specific overflow handling or printf
On Fri, Dec 13, 2002 at 04:41:06PM +0300, Andrey A. Chernov wrote:
> On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote:
> > Pardon my ignorance here, but the following fragment
> > returns -1, doesn't it?
> >
> > #include
> > void
> > main(void)
> > {
> > int i;
> >
> >
On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote:
> Pardon my ignorance here, but the following fragment
> returns -1, doesn't it?
>
> #include
> void
> main(void)
> {
> int i;
>
> i = (unsigned char)1 - (unsigned char)2;
> printf("%d\n", i);
> }
It very depe
On Fri, Dec 13, 2002 at 03:26:54PM +0300, Andrey A. Chernov wrote:
> Since both operands are unsigned, result can't be negative, but supposed
> to be. Here is the fix:
>
> --- b.c.bak Fri Dec 13 14:54:12 2002
> +++ b.c Fri Dec 13 15:20:15 2002
> @@ -292,7 +292,7 @@
> s[0][0] = a;
>
Since both operands are unsigned, result can't be negative, but supposed
to be. Here is the fix:
--- b.c.bak Fri Dec 13 14:54:12 2002
+++ b.c Fri Dec 13 15:20:15 2002
@@ -292,7 +292,7 @@
s[0][0] = a;
s[1][0] = b;
if ((r = strcoll(s[0], s[1])) == 0)
- r = (
>> On Thu, 14 Nov 2002 17:37:50 -0800, David Schultz
>> <[EMAIL PROTECTED]> said:
Da> You can work around the problem by disabling -fschedule-insns or
Da> -fstrict-aliasing, both of which are turned on by -O2. The latter
Da> option is the more direct cause of your problem, but for some
Da> reason
Thus spake TOMITA Yoshinori <[EMAIL PROTECTED]>:
> But unfortunately, that ugly code was contained in our inhouse library
> written by someone.
> It took me two days to debug and find out where difference comes from
> between gcc-2.95.4 and gcc-3.2.1.
You can work around the problem by disabling -
*/
> PCPU_LAZY_INC(cnt.v_syscall);
>
> --- snip
>
> This seems to be a macro to update a per-CPU variable. But, AFAIK, there is
> *only* one variable now. Is it correct?
>
> The ia64 version (/usr/src/sys/ia64/ia64) happily updates this variable:
> ...
This par
writing for FreeBSD.
>
> Is this a bug? If it is not, is there another system call counter available?
This is a bug in rev.1.62 of vm_meter.c and associated changes. I use
the following fix:
%%%
Index: pcpu.h
===
RCS file:
;
struct proc *p;
int error = 0;
u_int64_t oldip, oldri;
u_int sticks;
cnt.v_syscall++;
snip
What happens here? Is this a bug caught in the middle of a change?
BTW... Is there a major change in the sysctl MIB for 5.0-RELEASE? I am using
it to get most of
(www.orcaware.com) data collector I am
writing for FreeBSD.
Is this a bug? If it is not, is there another system call counter available?
Thanks in advance,
Borja.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the b
Galen Sampson wrote:
> One thing that I found interesting during mergemaster was the grouping of
> changes. For instance mergemaster determined that my /etc/group file was
> lacking some groups. The 4 groups that needed changing were on adjacent lines.
> Mergemaster gave me the option of mergin
On Tue, Nov 12, 2002 at 05:53:03PM -0800, Galen Sampson wrote:
> IIRC the old mergemaster merged changes like this one line at a time.
I don't recall it ever behaving this way, but I could be wrong.
Kris
msg46594/pgp0.pgp
Description: PGP signature
Hello All,
I just cvsup'd -current last night and ran "make buildworld, make buildkernel,
make installkernel, reboot, make installworld, mergemaster" (thus updating my
system from a May -current).
One thing that I found interesting during mergemaster was the grouping of
changes. For instance mer
On Mon, 11 Nov 2002, David Malone wrote:
DM>On Mon, Nov 11, 2002 at 04:52:22PM +0100, Harti Brandt wrote:
DM>AG>But does using a union make it safe?
DM>
DM>> Well, I just had a long discussion with a collegue about the topic. The
DM>> main problem is in the ISO-C standard, section 6.7 point 4 whic
On Mon, Nov 11, 2002 at 04:52:22PM +0100, Harti Brandt wrote:
AG>But does using a union make it safe?
> Well, I just had a long discussion with a collegue about the topic. The
> main problem is in the ISO-C standard, section 6.7 point 4 which states:
>
> All declarations in the same scope that re
TOMITA Yoshinori wrote:
> Yes, I agree with your example code.
>
> But unfortunately, that ugly code was contained in our inhouse library
> written by someone.
> It took me two days to debug and find out where difference comes from
> between gcc-2.95.4 and gcc-3.2.1.
And half a day to fire the pe
Harti Brandt <[EMAIL PROTECTED]> wrote:
>
> Yes, of course, but one would assume it to work (I suppose there is a
> large amount of code that assumes it will work).
Not a safe assumption at all. For example, what if the alignment
requirements for `short' and `int' are different (as they frequ
On Mon, 11 Nov 2002, Thomas David Rivers wrote:
TDR>Harti Brandt <[EMAIL PROTECTED]> wrote:
TDR>>
TDR>>
TDR>> Hmm, I though the following would work:
TDR>>
TDR>> void
TDR>> foo(unsigned short *s)
TDR>> {
TDR>> unsigned short temp;
TDR>>
TDR>> temp = s[0];
TDR>> s[0] = s[1];
TDR>> s[1] = te
Harti Brandt <[EMAIL PROTECTED]> wrote:
>
>
> Hmm, I though the following would work:
>
> void
> foo(unsigned short *s)
> {
> unsigned short temp;
>
> temp = s[0];
> s[0] = s[1];
> s[1] = temp;
> }
>
> main()
> {
> int i = 0x12345678;
>
> foo(&i);
> p
Harti Brandt <[EMAIL PROTECTED]> wrote:
>
> Well, I just had a long discussion with a collegue about the topic. The
> main problem is in the ISO-C standard, section 6.7 point 4 which states:
>
> All declarations in the same scope that refer to the same object or
> function shall specify compatibl
On Mon, 11 Nov 2002, Andrew Gallatin wrote:
AG>
AG>Harti Brandt writes:
AG> > On Mon, 11 Nov 2002, TOMITA Yoshinori wrote:
AG> >
AG> > This is probably not a bug, but a feature. You are not expected to access
AG> > a variable through a pointer to a non-compatible typ
Harti Brandt writes:
> On Mon, 11 Nov 2002, TOMITA Yoshinori wrote:
>
> This is probably not a bug, but a feature. You are not expected to access
> a variable through a pointer to a non-compatible type. int and short are
> not compatible. (see your ISO C standard on this top
>> On Mon, 11 Nov 2002 08:55:02 -0500 (EST), Thomas David Rivers <[EMAIL PROTECTED]>
>said:
Th> Several people have pointed out that using "volatile" will
Th> help with your code.
Th> But - even with the use of "volatile" - your code is invalid ANSI
Th> C.
--snip--
Thanks for your detailed
>
> For the source code below, compiling gcc -O2/-O3 seem to produce
> incorrect code.
>
> ---
> #include
> int main(int argc, char* argv[])
> {
> unsigned int x = 0x12345678;
> unsigned short tmp;
> printf("%x\n", x);
> tmp = ((unsigned short *)&x
-O2/-O3 was OK without volatile, I thought this must be
gcc-3.2 bug.
Thanks a lot, again.
--
TOMITA Yoshinori
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, 11 Nov 2002, TOMITA Yoshinori wrote:
This is probably not a bug, but a feature. You are not expected to access
a variable through a pointer to a non-compatible type. int and short are
not compatible. (see your ISO C standard on this topic).
Try to use ntohl(), htonl() for your problem
In message <[EMAIL PROTECTED]>, TOMITA Yoshinori
writes:
>For the source code below, compiling gcc -O2/-O3 seem to produce
>incorrect code.
>
>---
>#include
>int main(int argc, char* argv[])
>{
>unsigned int x = 0x12345678;
>unsigned short tmp;
>printf(
t-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.1 [FreeBSD] 20021009 (prerelease)
Is this a gcc bug or the source code problem ?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
When playing with jail earlier, I found an interesting bug in devfs. After
playing with devfs a bit more, I found that jail isn't necessary to cause
the bug to show itself. Here's a copy of the session. The problem should be
obvious.
edgemaster# uname -a
FreeBSD edgemaster.zombie.org 5
bargs=0x0, helparg=0x8136e7b "- Scripting command")
>at alias.c:329
>329 args++;
> Seems to be a optimization bug with gcc 3.2.1.
> Edit the Makefile to have -O in the CFLAGS instead of -O2 and
> it works fine. We should p
done.
In message <[EMAIL PROTECTED]>, "Peter Edwards" writes:
>ntfs_unmount has had this bug since v 1.1: there's a "ronly" variable that
>should be used to detect if the mount is read-only and affect the flags
>passed to the VOP_CLOSE of the dev
ntfs_unmount has had this bug since v 1.1: there's a "ronly" variable that
should be used to detect if the mount is read-only and affect the flags
passed to the VOP_CLOSE of the device vnode accordingly. It's never set to
anything other than zero, but the matching VOP_OPEN in
On Sun, Oct 06, 2002 at 04:10:55PM -0700, Kris Kennaway wrote:
> Can anyone else reproduce this in tcsh?
>
> rpcgen -s `perl -e 'print "a"x5'`
> Word too long.
I reported this to the tcsh people about 18 months ago, but I
don't think it was ever fixed.
David.
To Unsubscribe: send m
On 06-Oct-2002 (23:10:55/GMT) Kris Kennaway wrote:
> Can anyone else reproduce this in tcsh?
> rpcgen -s `perl -e 'print "a"x5'`
> Word too long.
Mee too mail. Using {50,500,5000} works, hang only with 5
(not tested with others numbers). Doing:
# echo {your_command}
print only "word to
Michael Nottebrock wrote:
> Kris Kennaway wrote:
>
>> Can anyone else reproduce this in tcsh?
>
>
> Yup. My -CURRENT here is two weeks old.
... reproducible in -STABLE, too.
Regards,
--
Michael Nottebrock
"And the reasons? There are no reasons."
msg44136/pgp0.pgp
Description: PGP sig
On Mon, 2002-10-07 at 01:10, Kris Kennaway wrote:
> Can anyone else reproduce this in tcsh?
>
> rpcgen -s `perl -e 'print "a"x5'`
> Word too long.
>
> And then tcsh will hang in a state unresponsive to signals.
>
> Kris
>
Hangs here, too. (this is stable!)
FreeBSD klamath.ankon.homeip.ne
Kris Kennaway wrote:
> Can anyone else reproduce this in tcsh?
Yup. My -CURRENT here is two weeks old.
--
Michael Nottebrock
| After years of using email, I'm still to dumb to hit Reply-All |
msg44132/pgp0.pgp
Description: PGP signature
Can anyone else reproduce this in tcsh?
rpcgen -s `perl -e 'print "a"x5'`
Word too long.
And then tcsh will hang in a state unresponsive to signals.
Kris
msg44131/pgp0.pgp
Description: PGP signature
ut the network appears
> dead (no packets appear to pass).
>
> Looks like maybe a tx driver bug. Anyone seen this with other NIC's?
I haven't had any problems doing read-only accesses of my nfs mounted
CVS respository via an fxp NIC.
There are definitely some issues in the vn
ons. nfsiod's 0, 1, and 2 are in
DL, 3 is in IL state. nfsiod 0 is sleeping on sbwait.
The -current machine is up to date. 100 Mb/s Ethernet. tx driver. When
the lockup occurs I can still login to the console but the network appears
dead (no packets appear to pass).
Looks like maybe a tx dr
On 13 Sep, Ian Dowse wrote:
> For example, if you hold the reference count at 1 while calling the
> cleanup function, it allows that function to safely add and drop
> references, but if that cleanup function has a bug that drops one
> too many references then you end up recursin
gs in the functions called when the reference count hits zero.
For example, if you hold the reference count at 1 while calling the
cleanup function, it allows that function to safely add and drop
references, but if that cleanup function has a bug that drops one
too many references then you end up re
Ian Dowse wrote:
> And I've just remembered a fifth :-) I think the old BSD code had
> both an `open' count and a reference count. The open count is a
> count of the real users of the vnode (it is what ufs_inactive really
> wants to compare against 0), and the reference count is just for
> places
In message <[EMAIL PROTECTED]>, Don Lewis writes:
>After looking at ufs_inactive(), I'd like to add a fourth proposal
And I've just remembered a fifth :-) I think the old BSD code had
both an `open' count and a reference count. The open count is a
count of the real users of the vnode (it is what
called from VOP_INACTIVE().
Here are the three proposed fixes along with their advantages and
disadvantages:
Inline the v_usecount decrement code in nfs_inactive()
+ Least intrusive fix for the recursion bug
- Adds a kludge to a kludge
Call VOP_INACTIVE() before decrementing the ref
In message <[EMAIL PROTECTED]>, Don Lewis writes:
>
>A potentially better solution just occurred to me. It looks like it
>would be better if vrele() waited to decrement v_usecount until *after*
>the call to VOP_INACTIVE() (and after the call to VI_LOCK()). If that
>were done, nfs_inactive() woul
I remember seeing this panic many months back. I had fixed this in our
Freebsd source base.
Here is the scenario:
vrele() {
if (vp->v_usecount == 1) {
vp->usecount--;
if (VSHOULDFREE(vp))
vfree(vp);
vn_lock(vp, LK_EXCLUS
On 10 Sep, Don Lewis wrote:
> It looks like the call to vrele() from vn_close() is executing the
> following code:
>
> if (vp->v_usecount == 1) {
> vp->v_usecount--;
> /*
> * We must call VOP_INACTIVE with the node locked.
>
I've gotten a couple "lockmgr: locking against myself" panics today and
it seems to be somewhat reproduceable. I had the serial console hooked
up for the last one, so I was able to get a stack trace:
panic: lockmgr: locking against myself
Debugger("panic")
Stopped at Debugger+0x45: xchgl
On Sat, 7 Sep 2002, Bruce A. Mah wrote:
> If memory serves me right, Bruce Evans wrote:
> > libmd is also broken for some cases involving pipes. IIRC, this is
> > caused by the bogus st_size checks in the same function. st_size is
> > only valid for regular files.
>
> It's puzzling that the cal
6/usr/include/g++/bits/locale_facets.h:1057: Internal
compiler error in tsubst_decl, at cp/pt.c:5774
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
*** Error code 1
I can provide the current-relative pa
; Thanks, and "me too".
>
> Warnings are mostly turned off for not unimportant places like libraries
> since these places are too poorly written to compile without warnings.
Apparently.
> > PS. Actually I'm surprised that nobody caught the problem in the past
> &
s like libraries
since these places are too poorly written to compile without warnings.
> PS. Actually I'm surprised that nobody caught the problem in the past
> five months...this bug prevented release builds from 5-CURRENT hosts.
> Maybe I'm the only person crazy enough to t
t;
>Thanks, and "me too".
>
>Bruce.
>
>PS. Actually I'm surprised that nobody caught the problem in the past
>five months...this bug prevented release builds from 5-CURRENT hosts.
>Maybe I'm the only person crazy enough to try this. :-)
I tried that but i
If memory serves me right, Poul-Henning Kamp wrote:
> Good catch.
>
> I'm surprised the compiler doesn't whine.
Thanks, and "me too".
Bruce.
PS. Actually I'm surprised that nobody caught the problem in the past
five months...this bug prevented release b
On Fri, 6 Sep 2002, Alfred Perlstein wrote:
Alfred (thanks) found a bug in my code. Sorry for the fuss folks :-(.
> * Michal Mertl <[EMAIL PROTECTED]> [020906 06:10] wrote:
> > There seems to be bug in $SUBJ. When I run attached program on recent
> > -CURRENT, it always (
* Michal Mertl <[EMAIL PROTECTED]> [020906 06:10] wrote:
> There seems to be bug in $SUBJ. When I run attached program on recent
> -CURRENT, it always (after several seconds) triggers the bug. I first
> suspected a problem in the program's logic but on stable in runs just
>
Good catch.
I'm surprised the compiler doesn't whine.
Poul-Henning
>Index: mdXhl.c
>===
>RCS file: /usr/local/cvsroot/src/lib/libmd/mdXhl.c,v
>retrieving revision 1.16
>diff -u -r1.16 mdXhl.c
>--- mdXhl.c 25 Mar 2002 13:50:40
I think I've found a bug in libmd on -CURRENT, in which attempting to
compute the MD5 checksum (using MD5File(3)) of a zero-length file
generates an error. A trivial way to trigger this bug (which isn't
present in 4-STABLE) is:
ref4:bmah% uname -a
FreeBSD ref4.freebsd.org 4.7-
* Michal Mertl <[EMAIL PROTECTED]> [020906 06:10] wrote:
> There seems to be bug in $SUBJ. When I run attached program on recent
> -CURRENT, it always (after several seconds) triggers the bug. I first
> suspected a problem in the program's logic but on stable in runs just
>
There seems to be bug in $SUBJ. When I run attached program on recent
-CURRENT, it always (after several seconds) triggers the bug. I first
suspected a problem in the program's logic but on stable in runs just
fine.
Esentially I use piece of shm memory to pass some data between several
proc
[resent a few times, sorry if you receive the same messages]
Hi, I've found that there is a serious bug in sys/kern/subr_rman.c
about finding an acceptable region. I'm sure it's a obvious bug and
going to commit it soon, but this is my first commit to resource
manager code, so p
> > > I've been considering adding ANSI prototypes to tcpd.h, so we
> > > get more useful warnings from it.
>
> I have a local ISOfication (and lint cleanup) of tcp_wrappers that
> I've been meaning to contribute back to the author. Wanna play? :-)
Sure! Would appreciate if you send it to me )
R
> Such K&R way to declare functions sounds like an open invitation for
> bugs.
Agreed.
> > I've been considering adding ANSI prototypes to tcpd.h, so we
> > get more useful warnings from it.
I have a local ISOfication (and lint cleanup) of tcp_wrappers that
I've been meaning to contribute back
use they use it w/out an argument and
> > actual libwrap expects an argument.
>
> The bug would seem to be calling sock_host without an argument.
C++ complains if function was declared K&R style and used correctly.
So I had to change those declarations in tcpd.h to compile correctly.
On Sun, Aug 18, 2002 at 12:55:27AM -0400, Yuri Victorovich wrote:
> Is it a bug that function "sock_host" is declared
> sock_host() in /usr/include/tcpd.h
> but defined as sock_host(struct request_info *)
> in /usr/src/contrib/tcp_wrappers/socket.c ?
A fucntion whi
Is it a bug that function "sock_host" is declared
sock_host() in /usr/include/tcpd.h
but defined as sock_host(struct request_info *)
in /usr/src/contrib/tcp_wrappers/socket.c ?
Good question also why compiler passes this
and doesn't issue even a warning when I call it
with the a
On Thu, Aug 01, 2002 at 15:43:56 +0200, Alexander Leidinger wrote:
> Hi,
>
> we have a bug in setlocale(), it writes past
> static char new_categories[_LC_LAST][ENCODING_LEN + 1];
> in the do-while loop around line 159.
Thanx, fixed.
--
Andrey A. Chernov
http://ache.pp.ru/
Desription:
unauthorized write access to /etc directory using chfn/chsh commands in FreeBSD
5.0-CURRENT.
Contributing factors:
In FreeBSD 5.0, it is possible to fill up the whole partition by using chfn/chsh
commands. Normally, users have quotas set up on directories that are allowed to be
Hi,
we have a bug in setlocale(), it writes past
static char new_categories[_LC_LAST][ENCODING_LEN + 1];
in the do-while loop around line 159.
I get this backtrace
---snip---
(gdb) bt
#0 0x2816c9bc in kill () from /usr/lib/libc.so.4
#1 0x281af744 in abort () at /usr/src/lib/libc/../libc
On Mon, Jul 29, 2002 at 01:43:21AM +0930, Greg Lewis wrote:
> The patchset matches what is in the repository. Are you sure you've
> committed these changes?
I missed that changed some how, it's now commited. ;)
bill
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curr
quot; pthread_attr pthread_attr_default " to other name, the
> > compiler will pass.
> >
> > Does gcc31 have bug ?
>
> "Revisited"
>
> Do it like this:
>
> #undef pthread_attr_default
> #undef pthread_mutexattr_default
> #und
private.h:957: parse error before
> `__null'
> /usr/src/lib/libc_r/uthread/pthread_private.h:965: parse error before
> `__null'
...
>
> but if I change " pthread_attr pthread_attr_default " to other name, the
> compiler will pass.
>
> Does
java/jdk13/work/hotspot1.3.1/build/linux/linux_i486_core/jvmg'
> gmake: *** [jvmgcore] Error 2
>
>
> but if I change " pthread_attr pthread_attr_default " to other name, the
> compiler will pass.
>
> Does gcc31 have bug ?
Nope, #undef that symbol.
And try
On Sun, Jul 28, 2002 at 02:40:15PM +0800, Huang wen hui wrote:
> hi,
> I used gcc3.1 from ports to compile jdk1.3.1-p7 hotspot, I got problem
> in compiing /usr/src/lib/libc_r/uthread/pthread_private.h :
While I - unfortunately - do not know the solution to your problem, I
would like to report th
801 - 900 of 1463 matches
Mail list logo
