Re: Making adaptive redzones less aggressive
I can argue that this heuristic is totally relevant for 'int a[1100]' because lots of scientific code uses single-dimensional arrays as n-dimensional: #define N 100 int a[N * N]; ... a[i * N + j]; // off-by-one in 'i' will lead to off-by-N And no, I did not try to investigate if a better heuristic is possible. The basis for the current heuristic is that it does not increase the memory footprint (for globals) by more than X%. --kcc On Mon, Jul 17, 2017 at 2:41 AM, Yuri Gribov wrote: > On Mon, Jul 17, 2017 at 10:25 AM, 'Alexander Potapenko' via > address-sanitizer wrote: > > On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov > wrote: > >> Hi all, > >> > >> From reading the original feature request in > >> https://github.com/google/sanitizers/issues/8 it seems that adaptive > >> redzones were mainly meant for catching overflows in arrays of large > >> objects e.g. > >> > >> struct { > >> int a[10]; > >> int x; > >> } a[100]; > >> a[101].x = 0; // Skips redzone > >> > >> Current adaptation only considers size of array as a whole so would > >> add similarly big redzone for same-sized > >> > >> int a[1100]; > >> > >> even though risk of large overflow offset here seems to be much lower. > >> > >> Has anyone considered selecting redzone based on array element size > >> rather than array size? Firstly this would allow more intelligent > >> redzone selection (current approach does not guarantee that generated > >> redzone will cover one array element) and also reduce memory pressure > >> (which is important for "embedded" targets). > > > > I totally agree that for compound type arrays the redzone size must be > > based on the array element size. > > > > Not sure if we need to reduce the redzone size for big arrays of > > scalars, as e.g. char arrays are sometimes used as opaque storage for > > compound types. > > Good point. > > > Do you have any evidence how big is the memory overhead caused by > > redzones in this case? > > Not yet, this is something we'll need to investigate (my question was > mainly whether it makes sense to investigate this). > > -Y > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Making adaptive redzones less aggressive
On Mon, Jul 17, 2017 at 10:25 AM, 'Alexander Potapenko' via address-sanitizer wrote: > On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov wrote: >> Hi all, >> >> From reading the original feature request in >> https://github.com/google/sanitizers/issues/8 it seems that adaptive >> redzones were mainly meant for catching overflows in arrays of large >> objects e.g. >> >> struct { >> int a[10]; >> int x; >> } a[100]; >> a[101].x = 0; // Skips redzone >> >> Current adaptation only considers size of array as a whole so would >> add similarly big redzone for same-sized >> >> int a[1100]; >> >> even though risk of large overflow offset here seems to be much lower. >> >> Has anyone considered selecting redzone based on array element size >> rather than array size? Firstly this would allow more intelligent >> redzone selection (current approach does not guarantee that generated >> redzone will cover one array element) and also reduce memory pressure >> (which is important for "embedded" targets). > > I totally agree that for compound type arrays the redzone size must be > based on the array element size. > > Not sure if we need to reduce the redzone size for big arrays of > scalars, as e.g. char arrays are sometimes used as opaque storage for > compound types. Good point. > Do you have any evidence how big is the memory overhead caused by > redzones in this case? Not yet, this is something we'll need to investigate (my question was mainly whether it makes sense to investigate this). -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Making adaptive redzones less aggressive
On Sat, Jul 15, 2017 at 4:39 PM, Yuri Gribov wrote: > Hi all, > > From reading the original feature request in > https://github.com/google/sanitizers/issues/8 it seems that adaptive > redzones were mainly meant for catching overflows in arrays of large > objects e.g. > > struct { > int a[10]; > int x; > } a[100]; > a[101].x = 0; // Skips redzone > > Current adaptation only considers size of array as a whole so would > add similarly big redzone for same-sized > > int a[1100]; > > even though risk of large overflow offset here seems to be much lower. > > Has anyone considered selecting redzone based on array element size > rather than array size? Firstly this would allow more intelligent > redzone selection (current approach does not guarantee that generated > redzone will cover one array element) and also reduce memory pressure > (which is important for "embedded" targets). I totally agree that for compound type arrays the redzone size must be based on the array element size. Not sure if we need to reduce the redzone size for big arrays of scalars, as e.g. char arrays are sometimes used as opaque storage for compound types. Do you have any evidence how big is the memory overhead caused by redzones in this case? > -Y > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to address-sanitizer+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.