GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:03:31Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15668Allocations values for some compile tests are way too hight2019-07-07T18:03:31ZTamar ChristinaAllocations values for some compile tests are way too hightThese tests are failing on Windows (only), with way too high allocation counts. Quite when this started happening is not clear -- perhaps in the last couple of months.
```
bytes allocated value is too high:
Expected T12425(optasm...These tests are failing on Windows (only), with way too high allocation counts. Quite when this started happening is not clear -- perhaps in the last couple of months.
```
bytes allocated value is too high:
Expected T12425(optasm) bytes allocated: 139100464 +/-5%
Lower bound T12425(optasm) bytes allocated: 132145440
Upper bound T12425(optasm) bytes allocated: 146055488
Actual T12425(optasm) bytes allocated: 149370944
Deviation T12425(optasm) bytes allocated: 7.4 %
*** unexpected stat test failure for T12425(optasm)
bytes allocated value is too high:
Expected MultiLayerModules(normal) bytes allocated: 5619893176 +/-10%
Lower bound MultiLayerModules(normal) bytes allocated: 5057903858
Upper bound MultiLayerModules(normal) bytes allocated: 6181882494
Actual MultiLayerModules(normal) bytes allocated: 6693788656
Deviation MultiLayerModules(normal) bytes allocated: 19.1 %
*** unexpected stat test failure for MultiLayerModules(normal)
bytes allocated value is too high:
Expected T11303b(normal) bytes allocated: 54373936 +/-10%
Lower bound T11303b(normal) bytes allocated: 48936542
Upper bound T11303b(normal) bytes allocated: 59811330
Actual T11303b(normal) bytes allocated: 62015072
Deviation T11303b(normal) bytes allocated: 14.1 %
*** unexpected stat test failure for T11303b(normal)
bytes allocated value is too high:
Expected T12234(optasm) bytes allocated: 79889200 +/-5%
Lower bound T12234(optasm) bytes allocated: 75894740
Upper bound T12234(optasm) bytes allocated: 83883660
Actual T12234(optasm) bytes allocated: 91583520
Deviation T12234(optasm) bytes allocated: 14.6 %
*** unexpected stat test failure for T12234(optasm)
```
These are a bit too high for me to just blindly update them without knowing why.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15574C wrappers for Haskell foreign exports don't have finalizers (causes memory l...2019-07-07T18:04:04ZValoisaC wrappers for Haskell foreign exports don't have finalizers (causes memory leak).For each foreign export RTS creates a static C wrapper, which is initialized on `DLL_PROCESS_ATTACH`, but it has no finalizer/destructor to be called during `DLL_PROCESS_DETACH`. So it will stay alive till the program termination. That's...For each foreign export RTS creates a static C wrapper, which is initialized on `DLL_PROCESS_ATTACH`, but it has no finalizer/destructor to be called during `DLL_PROCESS_DETACH`. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, \*\*consumed memory is not fully released after freeing the library\*\*.
\[\[br\]\]\[\[br\]\]
There are four files attached to this ticket.
- \*\*HaskellExports.hs\*\* contains exact one foreign export function;
- \*\*CWrapper.cpp\*\* is supposed to contain wrappers to the Haskell functions, described in *HaskellExports.hs*, but it doesn't because they make no difference;
- \*\*main.cpp\*\*: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory);
- \*\*build.sh\*\* is a script for building the library.
\[\[br\]\]
The main program was built with MSVC 2015.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"C wrappers for Haskell foreign exports don't have finalizers (causes memory leak).","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For each foreign export RTS creates a static C wrapper, which is initialized on {{{DLL_PROCESS_ATTACH}}}, but it has no finalizer/destructor to be called during {{{DLL_PROCESS_DETACH}}}. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, **consumed memory is not fully released after freeing the library**.\r\n[[br]][[br]]\r\nThere are four files attached to this ticket. \r\n* **HaskellExports.hs** contains exact one foreign export function;\r\n* **CWrapper.cpp** is supposed to contain wrappers to the Haskell functions, described in ''HaskellExports.hs'', but it doesn't because they make no difference;\r\n* **main.cpp**: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory);\r\n* **build.sh** is a script for building the library.\r\n[[br]]\r\nThe main program was built with MSVC 2015.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12498Support unconventionally named import libraries2019-07-07T18:26:21ZTamar ChristinaSupport unconventionally named import librariesGHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of ...GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.
This would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file.
This should add more compatibility with packages on hackage.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support unconventionally named import libraries","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.\r\n\r\nInstead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.\r\n\r\nThis would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file. \r\n\r\nThis should add more compatibility with packages on hackage.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tamar ChristinaTamar Christina