Re: Creative ideas on how to debug heap corruption

Thanks everyone. I have indeed been trying to get somewhere with sanity checking. That used to help quite a bit for the deadstripping stuff that happened on iOS a long time ago, but that was also much more deterministic. Maybe I'll try to see if running it through qemu will give me some more

Re: COMPLETE pragmas

I'd be over the moon with happiness if I could hang COMPLETE pragmas on polymorphic types. I have 3 major issues with COMPLETE as it exists. 1.) Is what is mentioned here: Examples for me come up when trying to build a completely unboxed 'linear' library using backpack. In the end I want/need

Re: COMPLETE pragmas

Hooray Sebastian! Somehow, I knew cluing you into this conundrum would help find a solution. The approach you describe sounds quite plausible. Yet: types *do* matter, of course. So, I suppose the trick is this: have the COMPLETE sets operate independent of types, but then use types in the

Re: COMPLETE pragmas

Hi Richard, Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenberg < r...@richarde.dev>: > Hi Sebastian, > > I enjoyed your presentation last week at ICFP! > Thank you :) I'm glad you liked it! This thread ( >

Re: HsPragTick

I'm content with ripping it out and waiting to see if anyone complains. Without documentation or any obvious users, it seems hard to do otherwise. That said, if you reading this have a better idea than we do about who uses {-# GENERATED ... #-} pragmas, do speak up! Thanks, Richard > On Aug

COMPLETE pragmas

Hi Sebastian, I enjoyed your presentation last week at ICFP! This thread (https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms) played out before you became so interested in pattern-match coverage. I'd be curious

Re: Implicit reboxing of unboxed tuple in let-patterns

> On Aug 31, 2020, at 10:34 AM, Spiwack, Arnaud wrote: > > That being said, Richard seemed to feel rather strongly about this one. > Richard, do you still agree with your then position that let (#x, y#) = … > being a lazy pattern (hence implicitly boxes the pair) is the right semantics? I

WebUI for GHC/Haskell tooling (eventlog)

Hello, I've written a blog post about my WebUI based eventlog related tool. It is also related to eventlog2html and ghc-debug. I'm interested in your opinion and ideas related to ghc debug/profiling tooling. If you have time please read the post and it

Re: Implicit reboxing of unboxed tuple in let-patterns

I haven't used unboxed tuples enough to perhaps feel the pain, but on paper the current design makes sense to me. The laziness of the binding is suppose to have to do with the runtime rep of the binding itself, not any enclosing pattern. For example take     {-# LANGUAGE ScopedTypeVariables

Re: Creative ideas on how to debug heap corruption

Fuzzing: 1. generate simple random stg programs 2. compile and run with RTS sanity checking enabled 3. compare the program result between different backends The fuzzer should cover all codegen cases and all code in RTS. Maybe this could be checked by the existing tools. On Mon, Aug 31,

Re: Creative ideas on how to debug heap corruption

+Moritz On Mon, Aug 31, 2020 at 11:17 AM George Colpitts wrote: > I assume you're familiar with the following from > https://www.aosabook.org/en/ghc.html and that this facility is still > there. Just in case you are not: > > So, the debug RTS has an optional mode that we call *sanity checking*.

Re: Creative ideas on how to debug heap corruption

I assume you're familiar with the following from https://www.aosabook.org/en/ghc.html and that this facility is still there. Just in case you are not: So, the debug RTS has an optional mode that we call *sanity checking*. Sanity checking enables all kinds of expensive assertions, and can make the

Re: HsPragTick

I was under impression it was somehow related to HPC. Since I'm not sufficiently familiar with HPC's inner workings, I kept it around just to be safe. - Vlad On Mon, Aug 31, 2020, 17:03 Ryan Scott wrote: > I think that HsPragTick is unused as of [1]. In fact, I was under the > impression that

Re: Creative ideas on how to debug heap corruption

Dump the whole heap into file during GC traversal or taking the whole allocated area. hmm, maybe this is the same as core dump. On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier wrote: > > > > On 31 Aug 2020, at 5:54 pm, Moritz Angermann > wrote: > > > > If anyone has some create ideas, I'd love

Re: HsPragTick

I think that HsPragTick is unused as of [1]. In fact, I was under the impression that [1] removed HsPragTick entirely (as the commit message) would suggest, but upon further inspection, that doesn't appear to be the case. Vlad, do you recall why HsPragTick was kept around? Ryan S. - [1]

Re: Creative ideas on how to debug heap corruption

> On 31 Aug 2020, at 5:54 pm, Moritz Angermann > wrote: > > If anyone has some create ideas, I'd love to hear them. I've been wondering > if just logging allocations (offset, range, type) would help figuring out > what we > expected to be there; and then maybe try to break on the

Creative ideas on how to debug heap corruption

Hi there! as some of you may know, I've been working on an aarch64 native code generator. Now I've hit a situation where my stage2 compiler somehow corrupts my heap. Initially I thought this would likely be missing memory barriers, however they are emitted. This doesn't mean it can't be, but