replace definition of error with errorWithStackTrace

Brandon Allbery allbery.b at gmail.com
Thu Dec 18 06:02:53 UTC 2014 

On Wed, Dec 17, 2014 at 11:31 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:
>
> and ... currently exceptions / error dont trigger a core dump right? So
> how on earth will i get that dwarf stack trace? (seriously, i'm really
> ignorant :) )
>

In the general case, if you use a library that can understand binary
formats and extract debug information (e.g. GNU libbfd), you can implement
your own. There are also ways to do it without a library, although
portability can be a concern in that case. That said, my understanding of
the GHC DWARF stuff is that it's statically integrated with code
generation, such that the runtime can use it to print a meaningful stack
trace without the runtime overhead of profiling.

Note that it's not necessary or even useful to do a full stack trace in
this case --- for example, given how Haskell evaluation works, the whole
notion of printing parameters is hazy at best, especially when the
parameter is a function. So emulating --- or indeed using --- a debugger to
get the stack trace is both overkill and pointless.


> On Wed, Dec 17, 2014 at 11:23 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>>
>> sure, will GHC provide that out of the box for 7.10 though? It sounds
>> like it'll require exceptions to "core dump" right? and then use lldb or
>> gdb or something related?
>>
>> On Wed, Dec 17, 2014 at 2:10 AM, Johan Tibell <johan.tibell at gmail.com>
>> wrote:
>>>
>>> The idea with using dwarf info is that error (and all exception
>>> messages) would always include a stack trace automatically, just like in
>>> other languages.
>>> On Dec 17, 2014 5:49 AM, "Christopher Allen" <cma at bitemyapp.com> wrote:
>>>
>>>> I don't think the dwarf information replaces the utility of this
>>>> proposal, this proposal, critically, will help the new users who won't know
>>>> how to use debugging information. It'll also give people useful first-pass
>>>> information for reproducing the error for later, more detailed debugging.
>>>>
>>>> I'd very much like to see this happen if there aren't technical
>>>> arguments against it.
>>>>
>>>> --- Chris Allen
>>>>
>>>>
>>>> On Tue, Dec 16, 2014 at 10:38 PM, Carter Schonwald <
>>>> carter.schonwald at gmail.com> wrote:
>>>>>
>>>>> if the dwarf information work is landing in 7.10 (as it seems to be),
>>>>> perhaps my proposal is moot. But either way, making error "foo" and friend
>>>>> more informative by default would be a great thing to make sure happens.
>>>>>
>>>>> I think we had a clear majority supporting this proposal, but i think
>>>>> *some* basic dwarf support got merged in today?
>>>>>
>>>>> -Carter
>>>>>
>>>>> On Tue, Dec 2, 2014 at 5:02 AM, Johan Tibell <johan.tibell at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Why don't we use the DWARF information instead? It has no runtime
>>>>>> overhead so it can actually be turned on always. It also integrates with
>>>>>> all the standard open source tooling.
>>>>>>
>>>>>> On Tue, Dec 2, 2014 at 10:04 AM, Simon Peyton Jones <
>>>>>> simonpj at microsoft.com> wrote:
>>>>>>
>>>>>>>   +1, as I don't see a downside. However, I don't think this change
>>>>>>> is a sufficient change as long as stack traces are only available for
>>>>>>> profiled builds. I still wish something like rewrite-with-location[1],
>>>>>>> which even addresses explicit stack traces directly[2]. IIRC, last time
>>>>>>> that feature was brought up for discussion, it stalled due to disagreements
>>>>>>> on the right design.
>>>>>>>
>>>>>>> I think we have something of a consensus forming around
>>>>>>> https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations,
>>>>>>> see #9049.   It’s simple, non-invasive, and predicatable.  It does need
>>>>>>> someone to implement it though.   Simon Hengel is thinking about
>>>>>>> implementing it.  (He is the one who also suggested “rewrite with
>>>>>>> location”).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So I think we are stalled not so much on design but on
>>>>>>> implementation.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Simon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf
>>>>>>> Of *Michael Snoyman
>>>>>>> *Sent:* 01 December 2014 05:33
>>>>>>> *To:* Christopher Allen; Mark Wotton
>>>>>>> *Cc:* Haskell Libraries
>>>>>>> *Subject:* Re: replace definition of error with errorWithStackTrace
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +1, as I don't see a downside. However, I don't think this change is
>>>>>>> a sufficient change as long as stack traces are only available for profiled
>>>>>>> builds. I still wish something like rewrite-with-location[1], which even
>>>>>>> addresses explicit stack traces directly[2]. IIRC, last time that feature
>>>>>>> was brought up for discussion, it stalled due to disagreements on the right
>>>>>>> design.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [1] https://github.com/sol/rewrite-with-location
>>>>>>>
>>>>>>> [2]
>>>>>>> https://github.com/sol/rewrite-with-location#explicit-call-stacks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen <
>>>>>>> cma at bitemyapp.com> wrote:
>>>>>>>
>>>>>>>  +1 - I would be very happy if this happened.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton <mwotton at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>  having just spent a day tracking down a really uninformative error
>>>>>>> in Cabal, I'm all for this.
>>>>>>>
>>>>>>> On Mon Dec 01 2014 at 11:08:35 Carter Schonwald <
>>>>>>> carter.schonwald at gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorWithStackTrace
>>>>>>>
>>>>>>>
>>>>>>> has been in GHC for for >=1 major version,
>>>>>>>
>>>>>>> and for normal builds, acts just like error, BUT, when an error is
>>>>>>> thrown in a profiled build, it appends a stack trace with some basic source
>>>>>>> location data to the end of the error message!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think this change would benefit many!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> My current understanding is that the DWARF based approach to stack
>>>>>>> traces wont make it into  GHC 7.10 , and while this variant would only
>>>>>>> provide extra info in profiling builds (and strictly less than the dwarf
>>>>>>> work), its something that can definitely be done in a single small patch
>>>>>>> that could easily be swapped out for that improved approach once it lands.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> discussion period: 2 weeks unless theres a clear unanimous agreement
>>>>>>> to make the change ASAP, OR if the stack trace error stuff is landing in
>>>>>>> 7.10 and I'm misinformed!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>> -Carter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Libraries mailing list
>>>>>>> Libraries at haskell.org
>>>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Libraries mailing list
>>>>>>> Libraries at haskell.org
>>>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Libraries mailing list
>>>>>>> Libraries at haskell.org
>>>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Libraries mailing list
>>>>>>> Libraries at haskell.org
>>>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Libraries mailing list
>>>>>> Libraries at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>>
>>>>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141218/2baf514a/attachment.html>

More information about the Libraries mailing list