On Wednesday 19 August 2009 18:17, Chris Lattner wrote:> > But asserts and aborts don't go through that, right? What's needed is > > a way to get those assert and abort messages out to other compiler > > components so they have a chance to report them nicely to the user. > > assert and abort should never happen, just like a null pointer or > garbage pointer dereference should never happen. How are garbage > pointer and asserts different?And programs should never have bugs either. The reality is, they do. And when we screw up, we owe it to our users to give them as much information as possible and gracefully exit. We can't do that right now with the current LLVM assert/abort scheme. -Dave
On Aug 20, 2009, at 7:36 AM, David Greene wrote:> On Wednesday 19 August 2009 18:17, Chris Lattner wrote: > >>> But asserts and aborts don't go through that, right? What's >>> needed is >>> a way to get those assert and abort messages out to other compiler >>> components so they have a chance to report them nicely to the user. >> >> assert and abort should never happen, just like a null pointer or >> garbage pointer dereference should never happen. How are garbage >> pointer and asserts different? > > And programs should never have bugs either. > > The reality is, they do. And when we screw up, we owe it to our users > to give them as much information as possible and gracefully exit. We > can't do that right now with the current LLVM assert/abort scheme. >Hi Dave, These asserts are designed to be disabled entirely in a release build of llvm. Why is it so important to you to get user-friendly diagnostics for them when they aren't guaranteed to be there at all, and you'll likely be getting things like segfaults instead in a release build? Is your primary goal to be able to present a more consistent and friendly face to the user even when your application goes completely bonkers, does nasty stuff and needs to shut down? Or are you trying to use them as user-level diagnostics and continue on with broader processing? If the former, you should probably be catching things like SIGBUS and SIGSEGV already. Those errors are equivalent in severity to the sorts of things the debug asserts are catching. I'd suggest just adding SIGABRT to that list. If the latter, you're asking for a pretty fundamental change in the nature of things, and is why you're getting a ton of resistance. Regards, -Jim
On Thursday 20 August 2009 11:46, Jim Grosbach wrote:> These asserts are designed to be disabled entirely in a release build > of llvm. Why is it so important to you to get user-friendly > diagnostics for them when they aren't guaranteed to be there at all, > and you'll likely be getting things like segfaults instead in a > release build?We don't disable them in our release build because an abort message is at least a little more friendly than a fault with no information at all.> Is your primary goal to be able to present a more consistent and > friendly face to the user even when your application goes completely > bonkers, does nasty stuff and needs to shut down? Or are you trying to > use them as user-level diagnostics and continue on with broader > processing?The former. We certainly don't expect to continue processing.> If the former, you should probably be catching things like SIGBUS and > SIGSEGV already. Those errors are equivalent in severity to the sorts > of things the debug asserts are catching. I'd suggest just adding > SIGABRT to that list.We catch all of these things, but what we can't capture is the messages that go along with the asserts and aborts. They get dumped out rather randomly from the perspective of the user since they're output outside of the signal handling mechanism. I shouldn't think it would be too hard to design a more robust failure mechanism that provides some hooks for 3rd party messaging systems. Perhaps I'll work on that someday... :) -Dave