[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: weird error messages

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) | \
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 */
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!


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:       paul@wurtel.net      http://www.wurtel.demon.nl/
> work:       paul@murphy.nl       http://www.murphy.nl/
> debian:     paul@debian.org      http://www.debian.org/
> isdn4linux: paul@isdn4linux.org  http://www.isdn4linux.org/
> -- 
> To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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!

Reply to: