Re: FreeBSD and Debugging?
On Fri, Apr 09, 2004 at 10:17:08PM -0700, Lev Walkin wrote: Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ Wow!! This is excellent. Is anyone planning to add this to the ports collection? -- Craig Rodrigues http://crodrigues.org [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: passing messages to routing sockets
On Fri, Apr 09, 2004 at 08:02:30PM +0300, Vlad GALU wrote:
I understand that in order to add a new route to the routing
table, one must fill a buffer with an ifa_msghdr header, followed by three
socked adddress structures, representing the destination net/ip, the
netmask and the gateway.
[routing table suckiness snipped]
Could anyone provide a quick/small example on how to fill this
member ? I don't really understand what I should write into it.
It's a sucky one and I had to stare at src/sbin/route/* for a while til
the penny dropped. The netmasks in particular are packed in in a format
which isn't immediately obvious.
Have a look at the attached code, in particular, reply_rtmsg_resolve().
Also have a look at Section 19.11 of TCP/IP Illustrated Volume 2, and
Section 18.9 of UNIX Network Programming 3e Vol 1.
The API sucks, and it's something we'd like to change in future.
Regards,
BMS
/* $FreeBSD$ */
/*
* This is a hack to demonstrate the concept of hooking for the
* RTM_RESOLVE message being sent from the FreeBSD routing code,
* as a means of looking up routes on demand using a routing protocol
* such as AODV.
* This code will probably be vastly cleaned up and tested more thoroughly
* before being used as the basis for a user-space BSD AODV implementation.
*/
/*
* Copyright (c) 2003 Bruce M. Simpson [EMAIL PROTECTED]
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*must display the following acknowledgement:
*This product includes software developed by Bruce M. Simpson.
* 4. Neither the name of Bruce M. Simpson nor the names of co-
*contributors may be used to endorse or promote products derived
*from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY Bruce M. Simpson AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL Bruce M. Simpson OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include sys/param.h
#include sys/file.h
#include sys/socket.h
#include sys/sysctl.h
#include sys/ioctl.h
#include sys/sysctl.h
#include sys/types.h
#include sys/signal.h
#include net/if.h
#include net/if_var.h
#include net/if_mib.h
#include net/if_types.h
#include net/if_dl.h
#include net/route.h
#include netinet/in.h
#include netinet/if_ether.h
#include arpa/inet.h
#include netdb.h
#include ctype.h
#include err.h
#include errno.h
#include paths.h
#include signal.h
#include stdio.h
#include stdlib.h
#include string.h
#include sysexits.h
#include unistd.h
#include ifaddrs.h
union sockunion {
struct sockaddr sa;
struct sockaddr_in sin;
struct sockaddr_dl sdl;
struct sockaddr_storage ss;
};
typedef union sockunion sockunion_t;
void usage(void);
int add_xresolve_route(char *ifname, struct sockaddr_in *sin, int bits);
int inet_cidr_aton(char *s, struct in_addr *pin, int *bits);
int create_if(char *ifname);
int destroy_if(char *ifname);
int if2sockaddr(char *ifname, struct sockaddr_dl *sdl);
int handle_rtmsg(struct rt_msghdr *rtm, int msglen);
int handle_rtmsg_resolve(struct rt_msghdr *rtm, int msglen);
int reply_rtmsg_resolve(struct sockaddr_in *sin);
/*
* We check for the existence of ifname.
*/
#if 1
#define _IFNAME disc1
#else
#define _IFNAME lo0
#endif
int rtsock = -1;
int created = 0;
char *ifname = _IFNAME;
void
sighand_term(int sig)
{
/*
* Destroying an interface is sufficient to delete the routes
* pointing to it.
*/
if (created)
destroy_if(ifname);
exit(EXIT_SUCCESS);
}
void
setup_signals(void)
{
struct sigaction sa, osa;
sa.sa_handler = sighand_term;
sa.sa_flags = 0;
sigemptyset(sa.sa_mask);
sigaction(SIGTERM, sa, osa);
sigaction(SIGINT, sa, osa);
sigaction(SIGQUIT, sa, osa);
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 07:23, Brandon Erhart wrote: Thank you. You are my new god. I had checked out a version of valgrind for BSD (one of the patches) and it failed to compile. Everything seems to be working, except I get this warning at the beginning of the program: Warning: ignoring --pointercheck=yes, because i386_set_ldt failed (errno=45) Sounds like you need options USER_LDT in you kernel. grtz, Daan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 06:17, Lev Walkin wrote: Brandon Erhart wrote: For Linux, I've seen valgrind (probably one of the best) as well as several others. In the commercial arena, Rational's PURIFY and Parasoft's INSURE++ work on every OS *but* BSD. Any particular reason for this? Are there any debuggers out there for BSD that will detect the heap/stack corruption!? Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ Or alternatively, a more up-to-date version (which the above is a snapshot of) at http://www.rabson.org/#valgrind. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MFCs needed in src/sys/sys/cdefs.h
# [EMAIL PROTECTED] / 2004-04-10 01:01:26 -0400: At 10:50 PM +0200 4/9/04, Roman Neuhauser wrote: This is an extended version of my previous email to hackers@ which hasn't attracted any attention. This time I'm mailing the authors too. I must have missed the earlier message... Perhaps because I was only talking about the peter's commit? :) Two revisions need MFC in src/sys/sys/cdefs.h: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/cdefs.h.diff?r1=1.78r2=1.79 Silences gobs of warnings in just about any libtool-using software. Fix for CURRENT commited: (5 months, 1 week ago) by peter. I have no opinion on this. It looks fine to me. It's unfortunate we're frozen now, but I don't really care if it gets merged now or when the freeze is lifted, someone just MFC it please. I was tinkering with some ports last week, and the sheer number of occurrences of those warnings almost made me roll over. Google didn't prove very useful beyound showing that the internet is full of them (think archived failed build reports, various bento-like systems, etc), all FreeBSD. As for the change you made, I agree it's not worth the trouble. -- If you cc me or remove the list(s) completely I'll most likely ignore your message.see http://www.eyrie.org./~eagle/faqs/questions.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 09:13, Craig Rodrigues wrote: On Fri, Apr 09, 2004 at 10:17:08PM -0700, Lev Walkin wrote: Valgrind is available for FreeBSD. http://eirikn.kerneled.com/valgrind/ Wow!! This is excellent. Is anyone planning to add this to the ports collection? It's still in development, see http://www.rabson.org/. A port would be nice though :). Arjan pgp0.pgp Description: signature
Re: FreeBSD and Debugging?
On Fri, 9 Apr 2004, Brandon Erhart wrote: Are there any debuggers out there for BSD that will detect the heap/stack corruption!? [standard disclaimer and note about self-promotion goes here :)] valgrind and electric fence are very good suggestions. my own personal pet project was adding guard pages to the system malloc. then linking malloc.conf - AFGJ or setenv MALLOC_OPTIONS and you can find bugs in all the software you run. it's less complete than a dedicated heap checker, but lightweight enough (well, 20% penalty may not be light for some) that i run with it full time. we've had a fairly significant amount of success with it finding bugs in software that just happened to work. http://www.zeitbombe.org/patches/malloc_guard.diff should apply pretty cleanly to freebsd's malloc.c -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird behavior with either reading or write()ing !?
Hello, This is a rather odd bug/weird behavior. Confidence is high that it is not logic in my code this time. Please read the following carefully! In a web-crawling program I am writing, I deal with several thousand fds at a time. I am using FreeBSD's KQueue to keep track of them all so that I may be notified when an event is pending on a given socket. The program works as it should for about 75% of the connections. The other 25% don't work so well. I have implemented read timeouts in the fashion that, whenever I am in the callback function for data being wait to be read off an fd (EVFILT_READ or whatever), I store the last time (via gettimeofday()) that data was read on that socket. Then, in my main loop, I check all sockets to see if the last time data was read isn't any greater than 10 seconds ago. However, I am receiving a lot of read timeouts. I keep track of the last response from the remote server, and the current state I'm in (E.G., sent another GET request on a keepalive connection). In several cases, I had received a response for the last page I requested, processed/parsed it, and sent down another request. However, data never got back to me. Even after 10 seconds. Hell, even after 30 seconds in some cases. What I am wondering is, is it possible for either my write() to be failing it's ability to get data to the remote site (I check the return value of write(), and its always returning the amount of bytes I am writing), or possibly for data to be being dropped per-se on my end by the kernel (no data waiting on the socket). I have all my sockets in O_NONBLOCK mode. To test the possibility of perhaps KQueue not notifying me of data waiting, or me not grabbing the event off the queue in time, I call a read() on the socket one last time when I catch the read timeout. Most of the time (99% of it) there is no data waiting. This all seems to be random. It's never consistent (same server) over several runs of the program. Any ideas folks? This has completely stumped me. Thanks for your support, Brandon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
