threadscope crashes on events from ghc-HEAD (2014-06-29) #37

Open
trofi opened this Issue Jun 29, 2014 · 7 comments

Comments

Projects
None yet
4 participants
@trofi
Contributor

trofi commented Jun 29, 2014

Today I've tried to dig a bit in ghc performance bug:
https://ghc.haskell.org/trac/ghc/ticket/9221

After building ghc itself with threadscope support (I might fail to do it properly!)
I've got the following eventlog:
http://code.haskell.org/~slyfox/threadscope-bug-2014-06-29/ghc-stage2.eventlog (~8MB)

threadscope crashes with very uninformative error:
$ threadscope: Maybe.fromJust: Nothing
It comes from SummaryView.hs: 'scan (fromJust mcap) statsAccum ev'

Trying to filter out such events does not help much:
threadscope: Bad shift length-32

May I ask you to add some error handling to have an idea what's went wrong?
'ghc-events show' does not seem to fail on that file.

Thanks!

@Mikolaj Mikolaj self-assigned this Jun 29, 2014

@Mikolaj

This comment has been minimized.

Show comment
Hide comment
@Mikolaj

Mikolaj Jun 30, 2014

Member

Thank you for the report. I've added a more informative error message.

I guess your patch or the HEAD itself is broken or (less likely) somebody didn't update ghc-events to match HEAD. Most of the 'ghc-events validate' modes fail on this evenlog and for a good reason.

If this problem persists, you should probably file a GHC bug report (events are issued with no cap assigned --- this should not be so hard to grep in GHC source). Please reopen or comment if you have any more info.

Member

Mikolaj commented Jun 30, 2014

Thank you for the report. I've added a more informative error message.

I guess your patch or the HEAD itself is broken or (less likely) somebody didn't update ghc-events to match HEAD. Most of the 'ghc-events validate' modes fail on this evenlog and for a good reason.

If this problem persists, you should probably file a GHC bug report (events are issued with no cap assigned --- this should not be so hard to grep in GHC source). Please reopen or comment if you have any more info.

@Mikolaj Mikolaj closed this Jun 30, 2014

@simonmar

This comment has been minimized.

Show comment
Hide comment
@simonmar

simonmar Jul 1, 2014

Member

Mikolaj, what is the "good reason" you refer to? ThreadScope is supposed to be forwards and backwards compatible to some extent, so new events shouldn't break it.

Member

simonmar commented Jul 1, 2014

Mikolaj, what is the "good reason" you refer to? ThreadScope is supposed to be forwards and backwards compatible to some extent, so new events shouldn't break it.

@simonmar simonmar reopened this Jul 1, 2014

@Mikolaj Mikolaj removed their assignment Jul 1, 2014

@Mikolaj

This comment has been minimized.

Show comment
Hide comment
@Mikolaj

Mikolaj Jul 1, 2014

Member

@simonmar: the "good reason" is that many events that are normally expected to have a cap, have Nothing assigned in the eventlog (it seems more and more events are generated cap-less as the program runs). TS is supposed to run OK on eventlogs that validate (ghc-events validate foo). There is no mention of new events in this report nor can I spot any in the eventlog. Please feel free to correct me, if I missed anything.

Member

Mikolaj commented Jul 1, 2014

@simonmar: the "good reason" is that many events that are normally expected to have a cap, have Nothing assigned in the eventlog (it seems more and more events are generated cap-less as the program runs). TS is supposed to run OK on eventlogs that validate (ghc-events validate foo). There is no mention of new events in this report nor can I spot any in the eventlog. Please feel free to correct me, if I missed anything.

@trofi

This comment has been minimized.

Show comment
Hide comment
@trofi

trofi Jul 1, 2014

Contributor
Contributor

trofi commented Jul 1, 2014

@dcoutts

This comment has been minimized.

Show comment
Hide comment
@dcoutts

dcoutts Jul 10, 2014

Member

Could this be relevant: https://ghc.haskell.org/trac/ghc/ticket/9003 ?

Yep, looks like the culprit. So 7.8.3 will work fine. We just have to decide if we can be bothered to make the ghc-events library able to read the broken files generated by 7.8.2.

Member

dcoutts commented Jul 10, 2014

Could this be relevant: https://ghc.haskell.org/trac/ghc/ticket/9003 ?

Yep, looks like the culprit. So 7.8.3 will work fine. We just have to decide if we can be bothered to make the ghc-events library able to read the broken files generated by 7.8.2.

@trofi

This comment has been minimized.

Show comment
Hide comment
@trofi

trofi Jul 30, 2014

Contributor

Looks like it was actually fresh ghc bug (in setNumCapabilities acconting function):
https://ghc.haskell.org/trac/ghc/ticket/9384

Contributor

trofi commented Jul 30, 2014

Looks like it was actually fresh ghc bug (in setNumCapabilities acconting function):
https://ghc.haskell.org/trac/ghc/ticket/9384

@Mikolaj

This comment has been minimized.

Show comment
Hide comment
@Mikolaj

Mikolaj Oct 22, 2014

Member

Looks like it was actually fresh ghc bug (in setNumCapabilities acconting function):
https://ghc.haskell.org/trac/ghc/ticket/9384

Indeed. I've just tested a ghc-events version fixed (by @jberthold in haskell/ghc-events#6) to work around the 9003 bug and it still fails to validate the original ghc-stage2.eventlog above (no wonder, caps are missing all over the place).

Member

Mikolaj commented Oct 22, 2014

Looks like it was actually fresh ghc bug (in setNumCapabilities acconting function):
https://ghc.haskell.org/trac/ghc/ticket/9384

Indeed. I've just tested a ghc-events version fixed (by @jberthold in haskell/ghc-events#6) to work around the 9003 bug and it still fails to validate the original ghc-stage2.eventlog above (no wonder, caps are missing all over the place).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment