Re: Future of -fsanitize-recover
On Tue, Jun 10, 2014 at 11:56 AM, Yuri Gribov tetra2...@gmail.com wrote: All, Are there plans to extend -fsanitize-recover beyond UBSan? It seems that adding this functionality to e.g. ASan would be trivial. I do not plan to add such functionality to asan and I am strongly opposed to it. It will create more problems to users and developers than it will solve. What are your reasons? -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: Future of -fsanitize-recover
What are your reasons? Collect more memory errors from a single run. E.g. I have an embedded system at hand which requires at least 20m for typical fix-compile-run cycle (and some steps like reflashing the device are manual). Being able to fix more than one error at once would significantly reduce debugging time. It will create more problems to users and developers than it will solve. Agreed, it may cause false positives, duplicated reports, etc. But it does not have to be enabled by default. -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: Future of -fsanitize-recover
On Tue, Jun 10, 2014 at 12:10 PM, Yuri Gribov tetra2...@gmail.com wrote: What are your reasons? Collect more memory errors from a single run. E.g. I have an embedded system at hand which requires at least 20m for typical fix-compile-run cycle (and some steps like reflashing the device are manual). Being able to fix more than one error at once would significantly reduce debugging time. Sometimes -- yes. But there are downsides: one bug may trigger another report and the user will spend time investigating more reports than needed. It will create more problems to users and developers than it will solve. Agreed, it may cause false positives, duplicated reports, etc. But it does not have to be enabled by default. These, and many more. Next time, someone will request suppressions. I remain unconvinced... -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: Future of -fsanitize-recover
there are downsides: one bug may trigger another report Doesn't UBSan have the same problem? the user will spend time investigating more reports than needed. True but that would be a concious trade-off. It will create more problems to users and developers than it will solve. Agreed, it may cause false positives, duplicated reports, etc. But it does not have to be enabled by default. These, and many more. Just FYI this works quite well for us in practice (we use patched gcc). E.g. I was able to detect and fix a dozen of bugs in large app in 3 or 4 iterations instead of 10. I remain unconvinced... I was expecting 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: Future of -fsanitize-recover
On Tue, Jun 10, 2014 at 1:26 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: On Tue, Jun 10, 2014 at 12:50 PM, Yuri Gribov tetra2...@gmail.com wrote: there are downsides: one bug may trigger another report Doesn't UBSan have the same problem? Maybe, but ubsan reports totally different kinds of bugs. Note that I am not opposed to -fsanitize-recover in tsan and msan (it's there already). I think the frontend option is actually ignored in tsan and msan, and this mode is enabled with -mllvm -msan-keep-going=1. This should be fixed, of course. the user will spend time investigating more reports than needed. True but that would be a concious trade-off. It will create more problems to users and developers than it will solve. Agreed, it may cause false positives, duplicated reports, etc. But it does not have to be enabled by default. These, and many more. Just FYI this works quite well for us in practice (we use patched gcc). E.g. I was able to detect and fix a dozen of bugs in large app in 3 or 4 iterations instead of 10. That's the price for not having extra complexity. --kcc I remain unconvinced... I was expecting 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. -- 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: Future of -fsanitize-recover
On Tue, Jun 10, 2014 at 3:42 AM, 'Evgeniy Stepanov' via address-sanitizer address-sanitizer@googlegroups.com wrote: On Tue, Jun 10, 2014 at 1:26 PM, Konstantin Serebryany konstantin.s.serebry...@gmail.com wrote: On Tue, Jun 10, 2014 at 12:50 PM, Yuri Gribov tetra2...@gmail.com wrote: there are downsides: one bug may trigger another report Doesn't UBSan have the same problem? Maybe, but ubsan reports totally different kinds of bugs. Note that I am not opposed to -fsanitize-recover in tsan and msan (it's there already). I think the frontend option is actually ignored in tsan and msan, and this mode is enabled with -mllvm -msan-keep-going=1. This should be fixed, of course. Oh, cool, we even have a bug ( https://code.google.com/p/memory-sanitizer/issues/detail?id=12). the user will spend time investigating more reports than needed. True but that would be a concious trade-off. It will create more problems to users and developers than it will solve. Agreed, it may cause false positives, duplicated reports, etc. But it does not have to be enabled by default. These, and many more. Just FYI this works quite well for us in practice (we use patched gcc). E.g. I was able to detect and fix a dozen of bugs in large app in 3 or 4 iterations instead of 10. That's the price for not having extra complexity. --kcc I remain unconvinced... I was expecting 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. -- 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. -- Alexey Samsonov, Mountain View, CA -- 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.
