On Mon, Apr 24, 2017 at 5:06 PM, Brian Paul <bri...@vmware.com> wrote: > On 04/22/2017 03:46 PM, Giuseppe Bilotta wrote: >> >> Makes sense. As Gustaw suggests, it _shouldn't_ happen, but there's >> nothing to lose in being cautious about it 8-). I'll respin this patch >> with the assert+return here. > > I just want to second that.
Unless I did something wrong, a v2 of the patch, with the assert+return should be floating around in the patchwork now 8-) But then again, it replaces a lot of the other assert+return with an unreachable, so you might not like that either 8-P > It's really bad when our driver crashes in the > hands of a customer. I'd rather have a rendering glitch than a crash. I'm > kind of worried about the proliferation of unreachable() in Mesa. Well, the obvious question would be why such unreachable code actually gets reached in the first place, but I guess it's not always easy to get the conditions under which these supposedly invalid codepaths get reached. Would it be possible to preserve the assert+return semantics with something similar to a Linux kernel WARN_ON? (Ideally even with debug backtrace support, but wrapping it all in a macro would allow this to be added at a later stage if deemed appropriate/possible). -- Giuseppe "Oblomov" Bilotta _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev