Re: mountd will not start at boot. Or function later...
On Thu, Oct 25, 2001 at 04:15:39PM +0300, Peter Pentchev wrote: > On Thu, Oct 25, 2001 at 04:13:09AM -0600, Joesh Juphland wrote: > > > > I cannot mount any of the NFS shares that I share from my server due to a > > problem with mountd and RPC. > > > > rc.conf looks like this: > > > > network_interfaces="lo0" > > removable_interfaces="wi0" > > nfs_server_enable="YES" > > nfs_server_flags="-t -u -n 4" > > > > When I boot, mountd bombs out - log files show: > > > > mountd[119]: can't register mount > > > You wouldn't happen to have a portmap_enable="NO" line in your rc.conf, > would you? portmap_enable="NO" is the default on -stable. -- || Seth Kingsley || Meow Meow Fluff Fluff || [EMAIL PROTECTED] || || rndcontrol -s 0 || PGP signature
Re: Simple x86 assembler question
Matthew Emmerton wrote: > > Hi all, > > This weekend I decided to do some assembly hacking on some object-only code > that I've lost the C source for. Since I haven't coded assembler for at > least 8 years, and I threw my x86 assembly manuals out when I moved 6 months > ago, there are a few things that are stumping me. > > In particular, am I interpreting these instructions correctly? > > 0x80839fb : movzbl (%edx,%eax,1),%eax > > Takes %eax + %edx, obtains the byte value in memory at that address, > zero-extends and places into %eax Correct. > 0x80839ff : movzwl 0xe90(%ebx,%eax,2),%edx > > Takes %eax + %ebx + 0xe90, obtains the word value in memory at that address, > zero-extends and places in %edx. Here the correct address is %eax*2 + %ebx + 0xe90 -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Simple x86 assembler question
On Sat, Oct 27, 2001 at 07:08:58PM -0400, Matthew Emmerton wrote: > In particular, am I interpreting these instructions correctly? > > 0x80839fb : movzbl (%edx,%eax,1),%eax > > > Takes %eax + %edx, obtains the byte value in memory at that address, > zero-extends and places into %eax > > 0x80839ff : movzwl 0xe90(%ebx,%eax,2),%edx > > Takes %eax + %ebx + 0xe90, obtains the word value in memory at that address, > zero-extends and places in %edx. http://www.baldwin.cx/386htm/toc.htm Specifically: http://www.baldwin.cx/386htm/MOVZX.htm -- || Seth Kingsley || Meow Meow Fluff Fluff || [EMAIL PROTECTED] || || rndcontrol -s 0 || PGP signature
RE: Simple x86 assembler question
On 27-Oct-01 Matthew Emmerton wrote: > Hi all, > > This weekend I decided to do some assembly hacking on some object-only code > that I've lost the C source for. Since I haven't coded assembler for at > least 8 years, and I threw my x86 assembly manuals out when I moved 6 months > ago, there are a few things that are stumping me. > > In particular, am I interpreting these instructions correctly? > > 0x80839fb : movzbl (%edx,%eax,1),%eax > > > Takes %eax + %edx, obtains the byte value in memory at that address, > zero-extends and places into %eax > > 0x80839ff : movzwl 0xe90(%ebx,%eax,2),%edx > > Takes %eax + %ebx + 0xe90, obtains the word value in memory at that address, > zero-extends and places in %edx. Almost. The '2' there is a multiplier on (I think) %eax, so it uses 'ebx + 2 * eax + 0xe90' for the memory address. Either that or 'eax + 2 * ebx + 0xe90'. Check the gas info page for the AT&T syntax to figure out exactly which. (Or use nasm's diassembler which turns out Intel format asm.) (ports/devel/nasm, ndisasm) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
Garance A Drosihn wrote: > >Until newsyslog is fixed to not be able to stage a > >denial of service attack against you, I really, really > >recommend against its use. > > Seems like it would be more user-friendly (to freebsd users > in general) to fix newsyslog, instead of just telling people > that they should not use it... If people "just don't use" > newsyslog, how does that guarantee that whatever they do > use will not have the same problem that you described? They will have to make their own solutions correct. Every engineer is responsible for the correctness of their code. All I'[m saying here is that there is a known level of incorrectness in newsyslog: use it at your peril. If you want to fix it, I'm sure people would appreciate the effort. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
boot -v capture
[Posted to freebsd-questions will little result. I figured I'd give -hackers a try before I give up and copy the output by hand.] Can anyone suggest a means by which to capture the 'boot -v' output without using a serial console? I'm stuck without any serial ports on my notebook. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
disabling dynamic route addition
Hi, Is there currently a way (sysctl, patch?) to disable dynamic route addition? We have a few very busy web servers here, and we're running in to a bug in FreeBSD 4.2 (which is related to a bug in previous versions of FreeBSD - the one that's fixed by lowering net.inet.ip.rtexpire to 10 from 3600) where the dynamic route table grows but never flushes completely. Here it is just as it hit the buffer space limit, according to vmstat -m: Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) routetbl608495 85570K 85570K 85570K 514029240 0 16,32,64,128,256 The sister server (round robin) is pretty high as well: routetbl280443 39437K 39443K 85570K 372177270 0 16,32,64,128,256 Also, if this happens again, what additional information could I grab so I or others could (hopefully) successfully find the bug? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot -v capture
On Sun, Oct 28, 2001 at 02:08:08PM -0500, Jon Parise wrote: > Can anyone suggest a means by which to capture the 'boot -v' > output without using a serial console? dmesg(8), so long as it doesn't overrun the buffer. -current is also writing boot messages to syslog presumably with the facility of kern.*. -- || Seth Kingsley || Meow Meow Fluff Fluff || [EMAIL PROTECTED] || || rndcontrol -s 0 || PGP signature
Re: boot -v capture
On Sun, Oct 28, 2001 at 12:39:34PM -0800, Seth Kingsley wrote: > > Can anyone suggest a means by which to capture the 'boot -v' > > output without using a serial console? > > dmesg(8), so long as it doesn't overrun the buffer. > > -current is also writing boot messages to syslog presumably with the > facility of kern.*. Ah, I should have been more specific. The machine is unable to boot, so I need to the 'boot -v' output to diagnose that problem first. It's a chicken-and-egg scenario. -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disabling dynamic route addition
On Sun, 28 Oct 2001, David Kirchner wrote: > Hi, > > Is there currently a way (sysctl, patch?) to disable dynamic route > addition? We have a few very busy web servers here, and we're running in > to a bug in FreeBSD 4.2 (which is related to a bug in previous versions of > FreeBSD - the one that's fixed by lowering net.inet.ip.rtexpire to 10 from > 3600) where the dynamic route table grows but never flushes completely. > Here it is just as it hit the buffer space limit, according to vmstat -m: > > Memory statistics by type Type Kern > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > routetbl608495 85570K 85570K 85570K 514029240 0 > 16,32,64,128,256 > > The sister server (round robin) is pretty high as well: > > routetbl280443 39437K 39443K 85570K 372177270 0 > 16,32,64,128,256 > > Also, if this happens again, what additional information could I grab so I > or others could (hopefully) successfully find the bug? Many dynamic route related changes have been made since 4.2, your bug may already be fixed. You should invest time in transitioning to 4.4. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disabling dynamic route addition
On Sun, Oct 28, 2001 at 11:47:16AM -0800, David Kirchner wrote: > Hi, > > Is there currently a way (sysctl, patch?) to disable dynamic route I asume your "dynamic" routes are simple redirects. sysctl -w net.inet.icmp.drop_redirect=1 or in /etc/rc.conf: icmp_drop_redirect="YES" Or get a better routing table in the first place. > addition? We have a few very busy web servers here, and we're running in > to a bug in FreeBSD 4.2 (which is related to a bug in previous versions of > FreeBSD - the one that's fixed by lowering net.inet.ip.rtexpire to 10 from > 3600) where the dynamic route table grows but never flushes completely. > Here it is just as it hit the buffer space limit, according to vmstat -m: What does netstat tells you about the expire time for these routes? How are they flagged? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot -v capture
On Sun, Oct 28, 2001 at 04:01:00PM -0500, Jon Parise wrote: > On Sun, Oct 28, 2001 at 12:39:34PM -0800, Seth Kingsley wrote: > > > > Can anyone suggest a means by which to capture the 'boot -v' > > > output without using a serial console? > > > > dmesg(8), so long as it doesn't overrun the buffer. > > > > -current is also writing boot messages to syslog presumably with the > > facility of kern.*. > > Ah, I should have been more specific. > > The machine is unable to boot, so I need to the 'boot -v' output > to diagnose that problem first. It's a chicken-and-egg scenario. If you have an IR interface which you can set to IRDA1 FreeBSD will see it a normal seriel interface. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Simple x86 assembler question
On Sun, Oct 28, 2001 at 09:21:33AM -0700, John Baldwin wrote: > Almost. The '2' there is a multiplier on (I think) %eax, so it uses > 'ebx + 2 * eax + 0xe90' for the memory address. Either that or 'eax + > 2 * ebx + 0xe90'. Check the gas info page for the AT&T syntax to > figure out exactly which. (Or use nasm's diassembler which turns out > Intel format asm.) (ports/devel/nasm, ndisasm) BTW, Gas now supports Intel syntax. * doc/c-i386.texi (i386-Arch): New section. (i386-Syntax): Mention .intel_syntax and .att_syntax. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Sat, Oct 27, 2001 at 12:26:22AM -0400, Mike Barcroft wrote: > Just to clarify. This is still a POLA violation. If a log file is > pulled out from underneath syslogd(8), one wouldn't expect it to start > logging again, even if the file was re-created. I disagree, if the file was re-created. Actually, I find it weird and counter intuitive that syslogd will not log to the files in the config file (/etc/syslog.conf) unless they already exists. It really feels like we are living with a programming bug 25 years later If I didn't want syslogd to log something, I would not have it in syslog.conf. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
problems with recurring SIGTRAP under gdb
Any idea why when I insert a breakpoint I get a SIGTRAP and can't continue any further? Is this a bug in the FreeBSD distribution's gdb? I don't see this behavior on any other platform that I am using. (Linux/ Solaris/ OSF1) I am only seeing on this particular application. The binary is 60MB dynamically linked (its 200MB on Solaris) it is linked against libc_r but I am currently running it single threaded. Any thoughts on correcting this would be much appreciated. This is 4.4-STABLE Cvsupped 2 weeks ago. %r gdb maytag.Rd GNU gdb 4.18 Copyright 1998 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 absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (gdb) b pf_open Breakpoint 1 at 0x804c6ae: file ../sim/freebsd/pf/pf.c, line 204. (gdb) r -zqp1 Starting program: /amd/ayr/vol/users2/home/kmacy/kmacy8/maytag.Rd -zqp1 No boot-time filesystem (/u/kmacy/p4/ontap/control4/prod/build/bfs.Rd) found. Using ethaddr 00:01:00:00:05:e3 Mon Oct 29 02:16:34 GMT [main_proc:info]: EMS engine initialized My sysid = 0x1 Partner sysid = 0x0 Mon Oct 29 02:16:34 GMT [main_proc:notice]: ,tapes not found: skipping tape simulator initialization. floppy boot? y /etc/modules/sample.mod : can't open : Device not configured NetApp Release /amd/raiders/vol/data2/build/scratch/kmacy/control4.561.295_22_34_40: Sun Oct 28 17:56:19 PST 2001 Copyright (c) 1992-2001 Network Appliance, Inc. Starting boot on Mon Oct 29 02:16:34 GMT 2001 DBG:disk_mode_sense_fc_page: v0.0 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.1 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.4 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.5 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.8 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.9 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.10 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.11 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.12 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.13 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.14 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.16 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.17 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.18 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.19 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.20 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.21 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v0.6 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.16 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.0 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.1 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.11 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.12 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.14 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.4 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.6 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.8 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.10 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.2 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.5 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.13 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.17 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.9 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.3 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.18 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.19 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.20 setting FC mode to 40 DBG:disk_mode_sense_fc_page: v1.21 setting FC mode to 40 Breakpoint 1, pf_open (unit=0x0, ethaddrs=0x299570b0 "", valid_addrs=0x29957090) at ../sim/freebsd/pf/pf.c:204 204 int n = 0; (gdb) n Program received signal SIGTRAP, Trace/breakpoint trap. pf_open (unit=0x0, ethaddrs=0x299570b0 "", valid_addrs=0x29957090) at ../sim/freebsd/pf/pf.c:204 204 int n = 0; (gdb) n Program received signal SIGTRAP, Trace/breakpoint trap. pf_open (unit=0x0, ethaddrs=0x299570b0 "", valid_addrs=0x29957090) at ../sim/freebsd/pf/pf.c:204 204 int n = 0; (gdb) s 0x28f66150 in _thread_sys_sigprocmask () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x28f66150 in _thread_sys_sigprocmask () from /usr/lib/libc_r.so.4 #1 0x28f2dd4d in _thread_kern_scheduler () from /usr/lib/libc_r.so.4 #2 0x0 in ?? () (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. pf_open (unit=0x0, ethaddrs=0x299570b0 "", valid_addrs=0x29957090) at ../sim/freebsd/pf/pf.c:204 204 int n = 0; (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. pf_open (unit=0x0, ethaddrs=0x299570b0 "", valid_addrs=0x29957090) at ../sim/freebsd/pf/pf.c:204 204
Re: syslogd and kqueue
David O'Brien <[EMAIL PROTECTED]> writes: > Actually, I find it weird and counter intuitive that syslogd will not > log to the files in the config file (/etc/syslog.conf) unless they > already exists. It really feels like we are living with a programming > bug 25 years later > > If I didn't want syslogd to log something, I would not have it in > syslog.conf. syslog.conf would require fields for user:group and permissions in order for that to work, otherwise syslogd would have no idea how you want your log files created. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disabling dynamic route addition
Mike Silbersack wrote: > > Also, if this happens again, what additional information could I grab so I > > or others could (hopefully) successfully find the bug? > > Many dynamic route related changes have been made since 4.2, your bug may > already be fixed. You should invest time in transitioning to 4.4. THere's an interesting bug that appears to still be present in 4.4, where if you create an IPSEC VPN, a ping to the other end of the tunnel gets there, comes all the way back, but is dropped by the local machine, if the dfefault route is the machine hosting the tunnel. If you remove the default route, and add a static route to the other end of the tunnel, pointing through the gateway host, there is no problem. Note that leaving a static route while having a default route still fails. The tcpdump on the pinging host sees the packet back, but the network stack of the host does not. Can't tell you if this is a problem in the gateway host doing a rewrite when it shouldn't, and the receiving host dropping it, or the receiving host being too picky about the source of the next hop for the echo reply... If you want reproduction direction, I might be able to wrangle them out of someone, but you will need at least 4 machines to run them. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
David O'Brien wrote: > Actually, I find it weird and counter intuitive that syslogd will not > log to the files in the config file (/etc/syslog.conf) unless they > already exists. It really feels like we are living with a programming > bug 25 years later > > If I didn't want syslogd to log something, I would not have it in > syslog.conf. The intents is to have the switchover be atomic, in that the messages are not split in the middle of a line between files, and in that the switchover can not result in the loss of any messages. By using the rename/create/signal approach, syslogd is guaranteed to log new messages to the old file, despite the rename, until signalled to close and reopen the file (or a new file of another name, if syslog.conf is changed). If it created the file itself, there would be a potential race issue that would remain unresolved, which is hidden by the seperation of the create and the subsequent signal. Personally, I think that changing the syslogd is at most a harmless thing, and at worst, something that can be safely ignored, so I view the proposed change as nothing more than someone making work for themselves. The _useful_ thing to do would be to roll the newsyslog functionality into syslogd; however, as a .conf file that is expected to be distributed over NIS, I think that doing the syntax change is probably a bad idea... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ip_icmp.c's ancient bug-feature (fixed)
Hello! Really micro patch :-) fixing odd behavior (well, in fact, I deem an error) of FreeBSD' ip_icmp.c. You might observe this bug doing traceroute while standing behind a GW's interface with several IP-addresses (aliases). In this case you always got ICMP.TIMXCEED (time exceeded) coming from IP-address which is the first on the interface, even if your box is not using this IP-address as its next-hop. Despite of the code selecting right IP-address for this purpose is working well it's being confused by wrong argument it is being given. This patch http://www.morning.ru/~poige/patchzone/ip_icmp.c.diff fixes namely this problem. P.S. It seems the same problem belongs to OpenBSD and, may be, for all *BSD derivatives. P.P.S. the PR is already sent, now waiting... -- Best regards, Igor. http://morning.ru/~poige To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote: > By using the rename/create/signal approach, syslogd is > guaranteed to log new messages to the old file, despite the > rename, until signalled to close and reopen the file (or a > new file of another name, if syslog.conf is changed). > > If it created the file itself, there would be a potential > race issue that would remain unresolved, which is hidden by > the seperation of the create and the subsequent signal. Come again? 1. syslogd calls open(2) with O_CREAT. At this point syslogd happily keeps the file open and writes to it. 2. I rename the file. As we all know, syslogd keeps writing to its open file. 3. syslogd is HUP'ed, goto #1. No muss, no fuss. So where is the race? Mike had the only justification so far -- that of permissions of the file. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Test Suites
Are there any test suite packages available similiar to Visual Test from Rational? Not necessarily with a GUI, but the ability to build test scripts to test features of applications written for BSD? Thanks. -- Tom Greenwalt (F.O.E.) Trancer Software Inc. [EMAIL PROTECTED] 9099 7th Street NE http://www.trancer.com/ Minneapolis, MN 55434-1113 http://www.trancer.com/~tomg When I'm good I'm very good, when I'm bad I'm better, -- But when I'm evil you better run. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Test Suites
* Thomas S. Greenwalt <[EMAIL PROTECTED]> [011028 23:04] wrote: > Are there any test suite packages available similiar to Visual Test from > Rational? Not necessarily with a GUI, but the ability to build test scripts > to test features of applications written for BSD? > Thanks. There's a tool called 'expect' you can probably find in the ports. There's a been a couple of books about it published. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Test Suites
DejaGNU is a testsuite around expect and tcl/tk that is more of a test suite builder. There's also something called TET from OpenGroup (http://www.opengroup.org) which some people think highly of (I'm just now familiarizing myself with it) On Sun, 28 Oct 2001, Alfred Perlstein wrote: > * Thomas S. Greenwalt <[EMAIL PROTECTED]> [011028 23:04] wrote: > > Are there any test suite packages available similiar to Visual Test from > > Rational? Not necessarily with a GUI, but the ability to build test scripts > > to test features of applications written for BSD? > > Thanks. > > There's a tool called 'expect' you can probably find in the ports. > > There's a been a couple of books about it published. > > -- > -Alfred Perlstein [[EMAIL PROTECTED]] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' >http://www.morons.org/rants/gpl-harmful.php3 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
MT-Safe wrapper around memcpy()?
I'm trying to figure out the best way to write a wrapper around memcpy() which can call fprintf() without winding up getting into a recursive loop. The problem is that fprintf() will call memcpy() and around and around we go. I can use a global variable to prevent this, but that usage isn't thread safe. I can make it thread safe by using pthread keys, but then i have to link in libc_r, and for non-pthreaded programs i don't want to do that. Anyone have any suggestions? Right now I'm almost thinking that I just need to directly patch libc and libc_r. It might be an ugly patch though, and I'd rather not have this patch mandate recompiling all of libc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MT-Safe wrapper around memcpy()?
* Lamont Granquist <[EMAIL PROTECTED]> [011029 00:43] wrote: > > I'm trying to figure out the best way to write a wrapper around memcpy() > which can call fprintf() without winding up getting into a recursive > loop. The problem is that fprintf() will call memcpy() and around and > around we go. > > I can use a global variable to prevent this, but that usage isn't thread > safe. I can make it thread safe by using pthread keys, but then i have to > link in libc_r, and for non-pthreaded programs i don't want to do that. > > Anyone have any suggestions? Right now I'm almost thinking that I just > need to directly patch libc and libc_r. It might be an ugly patch though, > and I'd rather not have this patch mandate recompiling all of libc. Where do you see mem* calling printf? -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MT-Safe wrapper around memcpy()?
* Alfred Perlstein <[EMAIL PROTECTED]> [011029 00:53] wrote: > * Lamont Granquist <[EMAIL PROTECTED]> [011029 00:43] wrote: > > > > I'm trying to figure out the best way to write a wrapper around memcpy() > > which can call fprintf() without winding up getting into a recursive > > loop. The problem is that fprintf() will call memcpy() and around and > > around we go. > > > > I can use a global variable to prevent this, but that usage isn't thread > > safe. I can make it thread safe by using pthread keys, but then i have to > > link in libc_r, and for non-pthreaded programs i don't want to do that. > > > > Anyone have any suggestions? Right now I'm almost thinking that I just > > need to directly patch libc and libc_r. It might be an ugly patch though, > > and I'd rather not have this patch mandate recompiling all of libc. > > Where do you see mem* calling printf? Uh, nevermind. :) Ok, what you want to do is use a nested flag in memcpy so you don't recurse, there's some code in libc that's conditionally compiled when compiling libc_r, _THREAD_SAFE or something is defined, once you find that then just simply use the global for non threaded programs and keys for threaded ones. best of luck, -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd and kqueue
"David O'Brien" wrote: | On Sun, Oct 28, 2001 at 07:40:34PM -0800, Terry Lambert wrote: | > By using the rename/create/signal approach, syslogd is | > guaranteed to log new messages to the old file, despite the | > rename, until signalled to close and reopen the file (or a | > new file of another name, if syslog.conf is changed). | > | > If it created the file itself, there would be a potential | > race issue that would remain unresolved, which is hidden by | > the seperation of the create and the subsequent signal. | | Come again? | | 1. syslogd calls open(2) with O_CREAT. At this point syslogd happily |keeps the file open and writes to it. | 2. I rename the file. As we all know, syslogd keeps writing to its open |file. | 3. syslogd is HUP'ed, goto #1. | | No muss, no fuss. So where is the race? | Mike had the only justification so far -- that of permissions of the | file. Here's a proposal to cope with that. Add an optional sub-field to any action field in syslog.conf that begins with a slash, perhaps in the form `:0640:root:wheel'. If the syslog.conf file has this thing on the pathname, add O_CREAT to the open(2), and set the permissions and ownership as specified. If any of the three parts is missing, don't whine, but process the other parts. If the optional sub-field is completely missing (or has bad elements), stick to the old behaviour. This handles POLA, as older syslog.conf files will produce the same results as always; while those who read the additional comments in the new files can implement the new behaviour. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
