On Thu, 2018-05-03 at 11:52 +0000, Dave Barach (dbarach) wrote: > Dear Marco, > > The condition that I'm testing for is different from the condition checked for > by -fsanitize=alignment. > > Let's say that someone defines a packed structure which is ten bytes long. > Clearly the compiler will not generate an aligned vector operation, nor will > -fsanitize=alignment complain. > > However, it doesn't make sense to allocate them in an aligned vector or pool - > to a 64-byte boundary - since only the first element of the vector/pool will > be aligned. Thanks for taking the time to explain. Now, it makes sense to me. > > The ASSERT I'm testing says that one of three things must be true: no > alignment request, or the object size evenly divides the alignment request, or > the alignment request evenly divides the object size. Got you. > > There are a certain number of mistakes to clean up. > > HTH... Dave Thanks, Marco > > -----Original Message----- > From: Marco Varlese <mvarl...@suse.de> > Sent: Thursday, May 3, 2018 3:02 AM > To: Dave Barach (dbarach) <dbar...@cisco.com>; Ray Kinsella <m...@ashroe.eu>; > v > pp-...@lists.fd.io > Subject: Re: [vpp-dev] segfault due to movaps unaligned access > > Hi Dave, > > On Wed, 2018-05-02 at 19:20 +0000, Dave Barach wrote: > > Quick update. I added the obvious ASSERT, and immediately found a > > couple of non-compliant data structures. With two (trivial) fixes, vpp > > makes it to the debug CLI prompt. I'm going to start looking at "make > > test-debug", to see how many additional issues we may encounter. > > Not sure if you missed my prev email but something I did in the past with this > sort of errors was to compile the code with "-fsanitize=undefined" (or even > simply -fsanitize=alignment). > In that way, you don't have to place ASSERT statements yourself around > "potential runtime error code" since the compiler will take care of > highlighting those instances when you launch the executable. > > Basically, once you compile it with that option and launch the tests you > should be in a position to see all misalignments highlighted. > > Don't know if you missed my email just wanted to follow up, maybe it might be > quicker? > > > Cheers, > Marco > > > > D. > > > > -----Original Message----- > > From: Dave Barach (dbarach) > > Sent: Tuesday, May 1, 2018 3:29 PM > > To: Ray Kinsella <m...@ashroe.eu>; vpp-dev@lists.fd.io > > Subject: RE: [vpp-dev] segfault due to movaps unaligned access > > > > Hey Ray, > > > > That's a good idea, and none too hard to implement. It's on my list. > > > > I'm a bit afraid of what I may find when I turn it on, but anyhow... > > > > Thanks... D. > > > > -----Original Message----- > > From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Ray > > Kinsella > > Sent: Tuesday, May 1, 2018 10:58 AM > > To: vpp-dev@lists.fd.io > > Subject: Re: [vpp-dev] segfault due to movaps unaligned access > > > > Is it worth to use an assert (or similar) to validate the assumption > > in the debug build at least. Well at least until the compiler bugs get's > > sorted? > > > > Ray K > > > > On 26/04/2018 17:08, Dave Barach wrote: > > > Yes, it’s arguably a compiler bug. > > > > > > But, it makes no sense to vec_validate_aligned(…), > > > pool_get_aligned(…) etc. objects whose size is not a multiple of the > > > alignment request. > > > Only the first element will be aligned to the specified boundary. > > > > > > __attribute__((aligned(xxx))) is not the same thing as ensuring that > > > objects are _sized_ correctly. > > > > > > D. > > > > > > *From:*vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> *On Behalf Of *Radu > > > Nicolau > > > *Sent:* Thursday, April 26, 2018 4:54 AM > > > *To:* Florin Coras <fcoras.li...@gmail.com> > > > *Cc:* vpp-dev@lists.fd.io > > > *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access > > > > > > Hi Florin, > > > > > > Thanks! The patch fixes the issue. > > > > > > Any idea why is it happening? > > > > > > Regards, > > > > > > Radu > > > > > > *From:*vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > > [mailto:vpp-dev@lists.fd.io] *On Behalf Of *Florin Coras > > > *Sent:* Tuesday, April 24, 2018 11:25 PM > > > *To:* Nicolau, Radu <radu.nico...@intel.com > > > <mailto:radu.nico...@intel.com>> > > > *Cc:* vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> > > > *Subject:* Re: [vpp-dev] segfault due to movaps unaligned access > > > > > > Hi Radu, > > > > > > Making the crypto_worker_main_t a full cache line in size (see patch > > > [1]) seems to solve the issue. Could you confirm? > > > > > > Florin > > > > > > [1] https://gerrit.fd.io/r/#/c/12086/ > > > > > > On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com > > > <mailto:radu.nico...@intel.com>> wrote: > > > > > > Hello all, > > > > > > We’re seeing a weird issue, that is a segfault that looks to be > > > caused by a movaps instruction that is trying to access an address > > > that is not 16 byte aligned. > > > > > > The call originates from a vec_validate_init_empty_aligned that has > > > the argument aligned to 16 bytes. > > > > > > I have seen something like this in the past, we couldn’t find a root > > > cause and considered it a GCC bug (version 5 then), but now it pops > > > up again on version 7, so probably it isn’t. > > > > > > Any idea? A snapshot of the gdb screen below. > > > > > > gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0 > > > > > > https://postimg.cc/image/9jy4p38at/ > > > > > > thanks and I will appreciate any help, > > > > > > Radu > > > > > > > > > > > > > > > > > > > > -- > Marco V > > SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB > 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg -- Marco V
SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9163): https://lists.fd.io/g/vpp-dev/message/9163 View All Messages In Topic (17): https://lists.fd.io/g/vpp-dev/topic/18058213 Mute This Topic: https://lists.fd.io/mt/18058213/21656 New Topic: https://lists.fd.io/g/vpp-dev/post Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656 Group Home: https://lists.fd.io/g/vpp-dev Contact Group Owner: vpp-dev+ow...@lists.fd.io Terms of Service: https://lists.fd.io/static/tos Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub -=-=-=-=-=-=-=-=-=-=-=-
