Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fails to parse profiling output #28

Open
recursion-ninja opened this issue May 21, 2019 · 3 comments
Open

Fails to parse profiling output #28

recursion-ninja opened this issue May 21, 2019 · 3 comments
Labels
bug

Comments

@recursion-ninja
Copy link

When I invoke profiteur:

profiteur pcg.prof-full-run
pcg.prof-full-run: endOfInput

Here's the input file (valid for 30 days).
@jaspervdj jaspervdj added the bug label May 22, 2019
@jaspervdj
Copy link
Owner

jaspervdj commented May 22, 2019 •
edited
Loading

This seems like it might be an error in the GHC RTS! The issue is at line 22944:

                           zipWithKey                                                                                                                                Data.Vector.NonEmpty                                                    src/Data/Vector/NonEmpty.hs:84:15-24                                                                         118891          0    0.0    0.0    73.3   80.8
                            >>=                                                                                                                                      Data.Vector.Fusion.Util                                                 Data/Vector/Fusion/Util.hs:36:3-18                                                                           11890229702412351    8.9   13.5    73.3   80.8
                             fmap                                                                                                                                    Data.Vector.Fusion.Stream.Monadic                                       Data/Vector/Fusion/Stream/Monadic.hs:(133,3)-(135,20)                                                        118903  153799689    0.0    0.1     0.0    0.1

A screenshot of the right part since that makes it easier to see what's going on:

long

It seems like the number of entries is simply too large which results in it being badly padded, making the parser think there's a missing number. If you insert a space at the right place there, you should be unblocked -- I will report this issue upstream.

@recursion-ninja
Copy link
Author

recursion-ninja commented May 22, 2019 •
edited
Loading

Thank you very much for diagnosing the issue! I have encountered this on and off for over a year on *.prof files from very long running programs. It's nice to know where the parse errors come from.

@jaspervdj
Copy link
Owner

Upstream ticket: https://gitlab.haskell.org/ghc/ghc/merge_requests/1008

bgamari pushed a commit to ghc/ghc that referenced this issue May 23, 2019
@jaspervdj
Fix padding of entries in .prof files
7230c44 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
bgamari pushed a commit to ghc/ghc that referenced this issue May 23, 2019
@jaspervdj
Fix padding of entries in .prof files
5dc90d5 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
ghc-mirror-bot pushed a commit to ghc/ghc that referenced this issue May 23, 2019
@jaspervdj
Fix padding of entries in .prof files
339d8e3 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
bgamari pushed a commit to ghc/ghc that referenced this issue May 25, 2019
@jaspervdj
Fix padding of entries in .prof files
40a79f3 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
bgamari pushed a commit to ghc/ghc that referenced this issue May 25, 2019
@jaspervdj
Fix padding of entries in .prof files
84a656a 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
ghc-mirror-bot pushed a commit to ghc/ghc that referenced this issue May 25, 2019
@jaspervdj
Fix padding of entries in .prof files
82823d9 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
bgamari pushed a commit to ghc/ghc that referenced this issue May 26, 2019
@jaspervdj
Fix padding of entries in .prof files
6e3cf07 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
bgamari pushed a commit to ghc/ghc that referenced this issue May 27, 2019
@jaspervdj
Fix padding of entries in .prof files
95b7917 
When the number of entries of a cost centre reaches 11 digits, it takes
up the whole space reserved for it and the prof file ends up looking
like:

    ... no.        entries  %time %alloc   %time %alloc

        ...
    ... 120918     978250    0.0    0.0     0.0    0.0
    ... 118891          0    0.0    0.0    73.3   80.8
    ... 11890229702412351    8.9   13.5    73.3   80.8
    ... 118903  153799689    0.0    0.1     0.0    0.1
        ...

This results in tooling not being able to parse the .prof file.  I
realise we have the JSON output as well now, but still it'd be good to
fix this little weirdness.

Original bug report and full prof file can be seen here:
<jaspervdj/profiteur#28>.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jaspervdj @recursion-ninja