These look as if, given a map file, they ought to be simple to find and fix, without necessarily understanding the what the code does (assuming the Trap gives you enough information where to look in a map file). It sounds like the kind of 'black box debugging' that I've done for the last year or so (don't tell my boss I still don't understand what the code does).
>From your analysis it appears there are 2 solutions. 1) Create an copy of the bytes in a way that a simple ->member access can read without trapping. 2) Supply unaligned read/write (inline) functions/macros Something along the lines of #define READ_8U(addr) \ (*((addr)&~7)>>(((addr)&7)<<3) | \ (*((addr&~7)+1)<<(64-((addr)&7)<<3)) Which is quite probably bogus as I haven't thought about what endianness the data is. These could be used to replace u64 key = pPacket->key; /* unaligned trap */ with u64 key = READ_8U(&pPacket->key); /* safe */ Do such inline function/macro definitions already exist somewhere (I find it very hard to believe they don't)? If so, then we're already armed with all the tools we need - perhaps one weekend we should all just grab a package and fix a trap each! Phil On Fri, 09 February 2001, Paul Slootman wrote: > On Fri 09 Feb 2001, Paul Slootman wrote: > > > > I'll see if I can have a look at snort for this; I prefer Chris > > I've had a look at this :-) > > It's always the same with packages that examine raw network stuff. > It's because the ethernet packet is snarfed, and then a pointer to > e.g. the IP part is passed to some other function that thinks it > has a pointer to a struct and tries to use that directly. I fix this > by allocating a separate struct for this (which is automagically > aligned properly), and then copy the data from the address given > into the new struct via memcpy (which does it byte by byte > (effectively), hence not needing the alignment (although I'm sure > some optimization takes place)). > > I've identified a couple of places where this needed to be done. > I've put up a test version (1.7-2.alpha.1) of snort at > http://www.murphy.nl/~paul/debian/snort/ ; the deb itself is > http://www.murphy.nl/~paul/debian/snort/snort_1.7-2.alpha.1_alpha.deb > > Please give any feedback (esp. any remaining unaligned accesses; > the first hex number is important in finding the place in the > source where the problem is). I may have introduced some wierdness > somewhere, so also please check it's still doing what it should be :-) > There may still be an unaligned access if you have token ring (yeah, > right, like anyone still uses IP over token ring on an alpha :-) > > > Paul Slootman > -- > home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ > work: [EMAIL PROTECTED] http://www.murphy.nl/ > debian: [EMAIL PROTECTED] http://www.debian.org/ > isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.org/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Mathematics should not have to involve martyrdom; Support Eric Weisstein, see http://mathworld.wolfram.com Find the best deals on the web at AltaVista Shopping! http://www.shopping.altavista.com
