RTS may emit a localized heap profile that hp2ps can't read
Summary
RTS's output printf("%f")
is incompatible with hp2ps's /[0-9.]*/
for some locales.
Steps to reproduce
Generate a heap profile after having invoked setlocale()
with a locale that
doesn't use a full stop '.' 0x2E as a decimal separator. For example "fr_FR".
I have a small test case at https://gitlab.haskell.org/jbm/ghc/-/tags/prof-locale-bug
Expected behavior
RTS output and hp2ps input ought to be compatible.
Discussion
There are more or less 3 ways of solving this.
- accept them as potentially incompatible (status quo)
- enforce POSIX on the generation side
- allow all locales on the parsing side
I'm rather in favor of option 2, considering:
-
the user is entitled to change the locale as they see fit, and we shouldn't prevent them from profiling a localized program. (for perspective, in my case, it was gi-glib who performed the
setlocale()
call) -
the parser on the hp2ps side is in pure Haskell, it's going to have a hard time accepting all possible locales as an input.
I have a candidate patch for that way of solving at https://gitlab.haskell.org/jbm/ghc/-/tags/prof-locale-patch
As mentioned above, I also have a demonstration test case, but I'm not sure how it could be made reproducible without requiring a specific locale to be deployed on every tester's environment.