make clean fails to rm /usr/src/contrib/groff/src/include/defs.h
Hi Hackers,
I just filed a send-pr on a bug, if someone writes a fix, please send-pr to
http://www.freebsd.org/cgi/query-pr.cgi?pr=146682
No patch, sorry, about to travel. Below a vebatim copy of what I sent.
( It may need some discussion before a fix, hence I did not
CC hackers@ the send-pr mail, to keep send-pr web lean. )
---
>From jhs@@@berklix.com Tue May 18 00:46:06 2010
Date: Tue, 18 May 2010 00:43:54 +0200 (CEST)
Message-Id: <201005172243.o4HMhs8V051385@@@fire.js.berklix.net>
To: FreeBSD-gnats-submit@@@freebsd.org
Subject: make clean fails to rm /usr/src/contrib/groff/src/include/defs.h
From: "Julian H. Stacey"
Reply-To: "Julian H. Stacey"
Cc: jhs@@@berklix.com
X-send-pr-version: 3.113
X-GNATS-Notify:
>Submitter-Id: current-users
>Originator:Julian H. Stacey
>Organization: http://berklix.com BSD Linux Unix Consultancy, Munich/Muenchen.
>Confidential: no
>Synopsis: make clean fails to rm /usr/src/contrib/groff/src/include/defs.h
>Severity: serious
>Priority: medium
>Category: gnu
>Class: sw-bug
>Release: FreeBSD 8.0-RELEASE amd64
>Environment:
System: FreeBSD fire.js.berklix.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Wed Apr
21 10:27:18 CEST 2010
jhs@@@fire.js.berklix.net:/usr1/src/sys/amd64/compile/FIRE64.small2 amd64
>Description:
There is a bug in groff. Description & manual fix below.
/usr/src/gnu/usr.bin/groff Makefiles should deal with these issues:
/usr/src/contrib/groff/src/include/defs.h
What creates it ? (ports?)
Should it be removed by make clean.
Should it be in /usr/obj not /usr/src
What about a /usr/src mounted read only.
The Problem: {
If you accidentally (**) create
/usr/src/contrib/groff/src/include/defs.h
A make clean fails to remove defs.h. A make compiles all these executables
grn grodvi groff grolbp grolj4 grops grotty post-grohtml pre-grohtml troff
with a non existant font paths in /usr/local (instead of, not as
well as, base fonts in /usr/share/groff_font ).
groff fails, so man fails & make world fails.
Tests if system affected:
ls -l /usr/src/contrib/groff/src/include/defs.h
echo hallo > ~/tmp/dummy.rof ; groff ~/tmp/dummy.rof | head -2
groff: can't find `DESC' file
groff:fatal error: invalid device `ps'
To see failing paths:
A good binary will return nothing on next command:
strings /usr/bin/groff | grep local | grep -v setlocale
/usr/local/bin
/usr/local/share/groff/site-font:\
/usr/local/share/groff/1.19.2/font:/usr/lib/font
cd /usr/bin; grep -l share/groff/site-font *
grn grodvi groff grolbp grolj4 grops grotty post-grohtml
pre-grohtml troff
truss groff ~/tmp/dummy.rof
open("/usr/local/share/groff/site-font/devps/DESC",
O_RDONLY,0666) ERR#2 'No such file or directory'
open("/usr/local/share/groff/1.19.2/font/devps/DESC",
O_RDONLY,0666) ERR#2 'No such file or directory'
open("/usr/lib/font/devps/DESC",
O_RDONLY,0666) ERR#2 'No such file or directory'
A good system should just have:
open("/usr/share/groff_font/devps/DESC",O_RDONLY,0666) = 2 (0x2)
cd /usr/src/contrib/groff/src/include
l defs.h # 541 Apr 27 23:37 defs.h
grep local defs.h # See full file at end of mail.
cd /usr/obj/usr/src ; Grep groff/site-font | sort # Binary file
gnu/usr.bin/groff/src/devices/grodvi/grodvi
gnu/usr.bin/groff/src/devices/grohtml/post-grohtml
gnu/usr.bin/groff/src/devices/grolbp/grolbp
gnu/usr.bin/groff/src/devices/grolj4/grolj4
gnu/usr.bin/groff/src/devices/grops/grops
gnu/usr.bin/groff/src/devices/grotty/grotty
gnu/usr.bin/groff/src/preproc/grn/grn
gnu/usr.bin/groff/src/preproc/html/pre-grohtml
gnu/usr.bin/groff/src/roff/groff/groff
gnu/usr.bin/groff/src/roff/troff/troff
gnu/usr.bin/groff/doc/groff.info
A better /usr/obj has just:
Grep groff/site-font | sort
Binary file ./usr/src/gnu/usr.bin/groff/doc/groff.info matches
}
How The Problem Arose: {
I'm not sure how defs.h got created on my system
cd /var/db/pkg ls | wc # 652 652 11818
uname -a
FreeBSD fire.js.berklix.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0:
Wed Apr 21 10:27:18 CEST 2010
jhs@@@fire.js.berklix.net:/usr1/src/sys/amd64/compile/FIRE64.small2 amd64
defs.h did not get created when I ran a make world within a chroot.
}
A Lot Of People Have Been Caught Over Time: {
Not perhaps a lot of FreeBSD people, though some, but this
groff path problem & too cryptic error message has catching people
for years on many architectures, eg paste this into google:
groff: can't find `DESC' file FreeBSD
& get this URL:
http://www.google.de/#hl=de&q=groff%3A+can%27t+find+%60DESC%27+file+FreeBSD&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=d778669e1739683f
}
The too cryptic erro
Re: hifn(4) DMA fix for review
On 2010-05-10, at 8:23 AM, Sam Leffler wrote: > > On May 7, 2010, at 12:13 PM, Oleksandr Tymoshenko wrote: > >> Proposed patch addresses hifn(4) problems on FreeBSD/mips. Current >> implementation keeps some of the state information (indexes in >> buffers, etc) in DMA-mapped memory and bus_dma code invalidates them >> during sync operations. This fix moves data that doesn't belong to DMA >> ring to softc structure. >> >> Patch: http://people.freebsd.org/~gonzo/hifn.diff >> Stats for original driver: >> http://people.freebsd.org/~gonzo/hifn.stats.orig.txt >> Stats for patched version: >> http://people.freebsd.org/~gonzo/hifn.stats.patched.txt >> >> > > The changes look fine and make sense (did something similar for some other > drivers for when the dma data structures were mapped uncached). I can't see > any performance change in your stats; but I'm just eyeballing the numbers > side-by-side. Was this on x86? (where there should be zero difference) It > would be good to present these numbers better (e.g. curves on the same graph, > ministat output, etc). I took some time to learn gnuplot and here is result: http://people.freebsd.org/~gonzo/hifn-cmp.png The red ones are data from original driver, the blue ones are patched. There are some fluctuations but I think they're OK. I made three measurements for original drivers and there are fluctuations too with comparable order of magnitude: http://people.freebsd.org/~gonzo/hifn-orig.png If it's OK - I'll commit fixes -- gonzo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Efficient way to determine when a child process forks or calls exec
- Original Message
> From: Dan McNulty
> To: freebsd-hackers@freebsd.org
> Sent: Mon, May 17, 2010 11:33:31 AM
> Subject: Efficient way to determine when a child process forks or calls exec
>
> Hi all,
>I have been experimenting with ptrace to determine when a
> child process forks or calls exec. Particularly, I have explored
> tracing every system call entry and exit similar to what the truss
> utility does, and for my case, the performance impact of tracing every
> system call is too great.
> Is there a more efficient way than tracing
> every system call entry and exit to determine when a child process forks,
> calls exec, or creates a new LWP?
You can do that very easily with DTrace's syscall provider
#!/usr/sbin/dtrace -s
syscall::fork:entry
{
self->traceme=1;
}
syscall::exec*:entry
/self->traceme/
{
printf("pid %d has called %s\n", pid, probefunc);
self->traceme=0;
}
Hope that helps
}
Thanks a lot for your
> help!
-Dan
___
> ymailto="mailto:freebsd-hackers@freebsd.org";
> href="mailto:freebsd-hackers@freebsd.org";>freebsd-hackers@freebsd.org
> mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To
> unsubscribe, send any mail to "
> ymailto="mailto:freebsd-hackers-unsubscr...@freebsd.org";
> href="mailto:freebsd-hackers-unsubscr...@freebsd.org";>freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Efficient way to determine when a child process forks or calls exec
On 05/17/2010 10:33, Dan McNulty wrote: > Hi all, > > I have been experimenting with ptrace to determine when a child > process forks or calls exec. Particularly, I have explored tracing > every system call entry and exit similar to what the truss utility > does, and for my case, the performance impact of tracing every system > call is too great. > > Is there a more efficient way than tracing every system call entry and > exit to determine when a child process forks, calls exec, or creates a > new LWP? > > Thanks a lot for your help! > -Dan Not sure if this is exactly what your looking for but have you looked into possibly using the audit system for tracking these things ? In its own way its really efficient and the utilities that are provided (auditreduce) you might just find a easier way to get the information your looking for. Regards, -- jhell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: adding "check option to md5(1) [was: md5(1) and cal(1) on -questions]
On 05/12/2010 04:01, Eitan Adler wrote:
>> D> 2. Why doesn't md5(1) have a "check" option? Seems to me requiring a
>> D> manual inspection is error-prone at best, and makes scripting
>> D> unecessarily complicated.
>
> Would something like the attached patch be good?
> It adds a -c option for a string to check against. It prints
> "[failed]" if the string does not match the files md5 unless in -q
> mode.
> It also returns 2 to indicate md5 match failure for use in scripts.
>
I have reviewed this patch for functionality and my final conclusion is
commit it.
Though I would like to see the same functionality that the GNU GPL'd
version of md5 has with the '-c' option and being able to check every
sum that is listed in a file against a file on disk(c), this version
brings the availability to doing the checking right from md5 and utils
from a script.
I have also edited the manual page portion of the patch to include the
'[-c string]' option in the SYNOPSIS section of the man pages. This
newly generated patch was generated from the root of the source tree.
# cd /path/to/src
# patch Index: sbin/md5/md5.1
===
--- sbin/md5/md5.1 (revision 208194)
+++ sbin/md5/md5.1 (working copy)
@@ -8,18 +8,22 @@
.Sh SYNOPSIS
.Nm md5
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Nm sha1
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Nm sha256
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Nm rmd160
.Op Fl pqrtx
+.Op Fl c Ar string
.Op Fl s Ar string
.Op Ar
.Sh DESCRIPTION
@@ -73,6 +77,8 @@
The hexadecimal checksum of each file listed on the command line is printed
after the options are processed.
.Bl -tag -width indent
+.It Fl c Ar string
+Compare files to this md5 string
.It Fl s Ar string
Print a checksum of the given
.Ar string .
@@ -101,7 +107,8 @@
and
.Nm rmd160
utilities exit 0 on success,
-and 1 if at least one of the input files could not be read.
+1 if at least one of the input files could not be read,
+and 2 if at least one file does not have the same hash as the -c option.
.Sh SEE ALSO
.Xr cksum 1 ,
.Xr md5 3 ,
Index: sbin/md5/md5.c
===
--- sbin/md5/md5.c (revision 208194)
+++ sbin/md5/md5.c (working copy)
@@ -44,6 +44,8 @@
int qflag;
int rflag;
int sflag;
+unsigned char* checkAgainst;
+intchecksFailed;
typedef void (DIGEST_Init)(void *);
typedef void (DIGEST_Update)(void *, const unsigned char *, size_t);
@@ -138,8 +140,13 @@
digest = 0;
failed = 0;
- while ((ch = getopt(argc, argv, "pqrs:tx")) != -1)
+ checkAgainst = NULL;
+ checksFailed = 0;
+ while ((ch = getopt(argc, argv, "c:pqrs:tx")) != -1)
switch (ch) {
+ case 'c':
+ checkAgainst = optarg;
+ break;
case 'p':
MDFilter(&Algorithm[digest], 1);
break;
@@ -173,12 +180,19 @@
failed++;
} else {
if (qflag)
- printf("%s\n", p);
+ printf("%s", p);
else if (rflag)
- printf("%s %s\n", p, *argv);
+ printf("%s %s", p, *argv);
else
- printf("%s (%s) = %s\n",
+ printf("%s (%s) = %s",
Algorithm[digest].name, *argv, p);
+ if (checkAgainst && strcmp(checkAgainst,p))
+ {
+ checksFailed++;
+ if (!qflag)
+ printf("%s","[ Failed ]");
+ }
+ printf("\n");
}
} while (*++argv);
} else if (!sflag && (optind == 1 || qflag || rflag))
@@ -186,6 +200,8 @@
if (failed != 0)
return (1);
+ if (checksFailed != 0)
+ return (2);
return (0);
}
@@ -198,12 +214,20 @@
size_t len = strlen(string);
char buf[HEX_DIGEST_LENGTH];
+ alg->Data(string,len,buf);
if (qflag)
- printf("%s\n", alg->Data(string, len, buf));
+ printf("%s", buf);
else if (rflag)
- printf("%s \"%s\"\n", alg->Data(string, len, buf), string);
+ printf("%s \"%s\"", buf, string);
else
- printf("%s (\"%s\") = %s\n", alg->name, string,
alg->Data(string, len, buf));
+ printf("%s (\"%s\") = %s", alg->name, string, buf);
+ if (checkAgains
Efficient way to determine when a child process forks or calls exec
Hi all, I have been experimenting with ptrace to determine when a child process forks or calls exec. Particularly, I have explored tracing every system call entry and exit similar to what the truss utility does, and for my case, the performance impact of tracing every system call is too great. Is there a more efficient way than tracing every system call entry and exit to determine when a child process forks, calls exec, or creates a new LWP? Thanks a lot for your help! -Dan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: /dev/null & zero inside chroot for make release
On Mon, May 17, 2010 at 12:20:07PM +0200, Bernd Walter wrote: > On Sat, May 15, 2010 at 05:32:41PM +0200, Tjado M?cke wrote: > > > > > Thanks for trying to help :-) But this is in Wrong. > > > Line 4 on that page: > > > Last updated: 2005-08-11 > > > 5 years later, FreeBSD-8.0 has via ls -l /dev/null > > > crw-rw-rw- 1 root wheel0, 31 May 15 14:17 /dev/null > > > so both major & minor numbers have changed, command now would be > > > mknod dev/null c 0 31 > > > which I already posted in my original Thu, 13 May 2010 19:44:58 +0200 > > > as having tried, but not good enough. > > > > > > As I posted Fri, 14 May 2010 21:59:23 +0200 (but you may not have > > > seen when you posted) > > > > > > > > > > Hm... i did this on 7.2 because chrooted scponly shell with WinSCP > > support needs it. In this case it works... > > But I'm wrong because the dev/null with my nod numbers doesn't work > > correctly and WinSCP looks only if this file is there :D > > On my 7.0-stable I have: > [192]cicely7> ls -al /dev/null > crw-rw-rw- 1 root wheel0, 14 May 17 12:11 /dev/null > > You may very well have you HDD under 2,2 and having any innocent program > writing it's output to it... > Fortunately it takes many devnodes until 2,2 is getting used. For very long time, the following two statements are true: - char devices only have magic property of being a door to the device drivers when living on devfs mount point. Character devices on UFS or any other non-devfs mounts do not provide access to the physical devices. - major and minor numbers of devfs nodes, as displayed by ls, are not persistent across reboot. mknod on devfs is only useful to unhide the rm'ed node. pgpaJB9ef7GUE.pgp Description: PGP signature
Re: /dev/null & zero inside chroot for make release
On Sat, May 15, 2010 at 05:32:41PM +0200, Tjado Mäcke wrote: > > > Thanks for trying to help :-) But this is in Wrong. > > Line 4 on that page: > > Last updated: 2005-08-11 > > 5 years later, FreeBSD-8.0 has via ls -l /dev/null > > crw-rw-rw- 1 root wheel0, 31 May 15 14:17 /dev/null > > so both major & minor numbers have changed, command now would be > > mknod dev/null c 0 31 > > which I already posted in my original Thu, 13 May 2010 19:44:58 +0200 > > as having tried, but not good enough. > > > > As I posted Fri, 14 May 2010 21:59:23 +0200 (but you may not have > > seen when you posted) > > > > > > Hm... i did this on 7.2 because chrooted scponly shell with WinSCP > support needs it. In this case it works... > But I'm wrong because the dev/null with my nod numbers doesn't work > correctly and WinSCP looks only if this file is there :D On my 7.0-stable I have: [192]cicely7> ls -al /dev/null crw-rw-rw- 1 root wheel0, 14 May 17 12:11 /dev/null You may very well have you HDD under 2,2 and having any innocent program writing it's output to it... Fortunately it takes many devnodes until 2,2 is getting used. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
