| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There should be no change in the output of the '+RTS -s' (summary)
report, or
the 'RTS -t' (one-line) report.
All data shown in the summary report is now shown in the machine
readable
report.
All data in RTSStats is now shown in the machine readable report.
init times are added to RTSStats and added to GHC.Stats.
Example of the new output:
```
[("bytes allocated", "375016384")
,("num_GCs", "113")
,("average_bytes_used", "148348")
,("max_bytes_used", "206552")
,("num_byte_usage_samples", "2")
,("peak_megabytes_allocated", "6")
,("init_cpu_seconds", "0.001642")
,("init_wall_seconds", "0.001027")
,("mut_cpu_seconds", "3.020166")
,("mut_wall_seconds", "0.757244")
,("GC_cpu_seconds", "0.037750")
,("GC_wall_seconds", "0.009569")
,("exit_cpu_seconds", "0.000890")
,("exit_wall_seconds", "0.002551")
,("total_cpu_seconds", "3.060452")
,("total_wall_seconds", "0.770395")
,("major_gcs", "2")
,("allocated_bytes", "375016384")
,("max_live_bytes", "206552")
,("max_large_objects_bytes", "159344")
,("max_compact_bytes", "0")
,("max_slop_bytes", "59688")
,("max_mem_in_use_bytes", "6291456")
,("cumulative_live_bytes", "296696")
,("copied_bytes", "541024")
,("par_copied_bytes", "493976")
,("cumulative_par_max_copied_bytes", "104104")
,("cumulative_par_balanced_copied_bytes", "274456")
,("fragmentation_bytes", "2112")
,("alloc_rate", "124170795")
,("productivity_cpu_percent", "0.986838")
,("productivity_wall_percent", "0.982935")
,("bound_task_count", "1")
,("sparks_count", "5836258")
,("sparks_converted", "237")
,("sparks_overflowed", "1990408")
,("sparks_dud ", "0")
,("sparks_gcd", "3455553")
,("sparks_fizzled", "390060")
,("work_balance", "0.555606")
,("n_capabilities", "4")
,("task_count", "10")
,("peak_worker_count", "9")
,("worker_count", "9")
,("gc_alloc_block_sync_spin", "162")
,("gc_alloc_block_sync_yield", "0")
,("gc_alloc_block_sync_spin", "162")
,("gc_spin_spin", "18840855")
,("gc_spin_yield", "10355")
,("mut_spin_spin", "70331392")
,("mut_spin_yield", "61700")
,("waitForGcThreads_spin", "241")
,("waitForGcThreads_yield", "2797")
,("whitehole_gc_spin", "0")
,("whitehole_lockClosure_spin", "0")
,("whitehole_lockClosure_yield", "0")
,("whitehole_executeMessage_spin", "0")
,("whitehole_threadPaused_spin", "0")
,("any_work", "1667")
,("no_work", "1662")
,("scav_find_work", "1026")
,("gen_0_collections", "111")
,("gen_0_par_collections", "111")
,("gen_0_cpu_seconds", "0.036126")
,("gen_0_wall_seconds", "0.036126")
,("gen_0_max_pause_seconds", "0.036126")
,("gen_0_avg_pause_seconds", "0.000081")
,("gen_0_sync_spin", "21")
,("gen_0_sync_yield", "0")
,("gen_1_collections", "2")
,("gen_1_par_collections", "1")
,("gen_1_cpu_seconds", "0.001624")
,("gen_1_wall_seconds", "0.001624")
,("gen_1_max_pause_seconds", "0.001624")
,("gen_1_avg_pause_seconds", "0.000272")
,("gen_1_sync_spin", "3")
,("gen_1_sync_yield", "0")
]
```
Test Plan: Ensure that one-line and summary reports are unchanged.
Reviewers: erikd, simonmar, hvr
Subscribers: duog, carter, thomie, rwbarton
GHC Trac Issues: #14660
Differential Revision: https://phabricator.haskell.org/D4529
|
|
|
|
| |
This reverts commit 2d4bda2e4ac68816baba0afab00da6f769ea75a7.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There should be no change in the output of the '+RTS -s' (summary)
report, or the 'RTS -t' (one-line) report.
All data shown in the summary report is now shown in the machine
readable report.
All data in RTSStats is now shown in the machine readable report.
init times are added to RTSStats and added to GHC.Stats.
Example of the new output:
```
[("bytes allocated", "375016384")
,("num_GCs", "113")
,("average_bytes_used", "148348")
,("max_bytes_used", "206552")
,("num_byte_usage_samples", "2")
,("peak_megabytes_allocated", "6")
,("init_cpu_seconds", "0.001642")
,("init_wall_seconds", "0.001027")
,("mut_cpu_seconds", "3.020166")
,("mut_wall_seconds", "0.757244")
,("GC_cpu_seconds", "0.037750")
,("GC_wall_seconds", "0.009569")
,("exit_cpu_seconds", "0.000890")
,("exit_wall_seconds", "0.002551")
,("total_cpu_seconds", "3.060452")
,("total_wall_seconds", "0.770395")
,("major_gcs", "2")
,("allocated_bytes", "375016384")
,("max_live_bytes", "206552")
,("max_large_objects_bytes", "159344")
,("max_compact_bytes", "0")
,("max_slop_bytes", "59688")
,("max_mem_in_use_bytes", "6291456")
,("cumulative_live_bytes", "296696")
,("copied_bytes", "541024")
,("par_copied_bytes", "493976")
,("cumulative_par_max_copied_bytes", "104104")
,("cumulative_par_balanced_copied_bytes", "274456")
,("fragmentation_bytes", "2112")
,("alloc_rate", "124170795")
,("productivity_cpu_percent", "0.986838")
,("productivity_wall_percent", "0.982935")
,("bound_task_count", "1")
,("sparks_count", "5836258")
,("sparks_converted", "237")
,("sparks_overflowed", "1990408")
,("sparks_dud ", "0")
,("sparks_gcd", "3455553")
,("sparks_fizzled", "390060")
,("work_balance", "0.555606")
,("n_capabilities", "4")
,("task_count", "10")
,("peak_worker_count", "9")
,("worker_count", "9")
,("gc_alloc_block_sync_spin", "162")
,("gc_alloc_block_sync_yield", "0")
,("gc_alloc_block_sync_spin", "162")
,("gc_spin_spin", "18840855")
,("gc_spin_yield", "10355")
,("mut_spin_spin", "70331392")
,("mut_spin_yield", "61700")
,("waitForGcThreads_spin", "241")
,("waitForGcThreads_yield", "2797")
,("whitehole_gc_spin", "0")
,("whitehole_lockClosure_spin", "0")
,("whitehole_lockClosure_yield", "0")
,("whitehole_executeMessage_spin", "0")
,("whitehole_threadPaused_spin", "0")
,("any_work", "1667")
,("no_work", "1662")
,("scav_find_work", "1026")
,("gen_0_collections", "111")
,("gen_0_par_collections", "111")
,("gen_0_cpu_seconds", "0.036126")
,("gen_0_wall_seconds", "0.036126")
,("gen_0_max_pause_seconds", "0.036126")
,("gen_0_avg_pause_seconds", "0.000081")
,("gen_0_sync_spin", "21")
,("gen_0_sync_yield", "0")
,("gen_1_collections", "2")
,("gen_1_par_collections", "1")
,("gen_1_cpu_seconds", "0.001624")
,("gen_1_wall_seconds", "0.001624")
,("gen_1_max_pause_seconds", "0.001624")
,("gen_1_avg_pause_seconds", "0.000272")
,("gen_1_sync_spin", "3")
,("gen_1_sync_yield", "0")
]
```
Test Plan: Ensure that one-line and summary reports are unchanged.
Reviewers: bgamari, erikd, simonmar, hvr
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14660
Differential Revision: https://phabricator.haskell.org/D4303
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
get/setAllocationCounter didn't take into account allocations in the
current block. This was known at the time, but it turns out to be
important to have more accuracy when using these in a fine-grained
way.
Test Plan:
New unit test to test incrementally larger allocaitons. Before I got
results like this:
```
+0
+0
+0
+0
+0
+4096
+0
+0
+0
+0
+0
+4064
+0
+0
+4088
+4056
+0
+0
+0
+4088
+4096
+4056
+4096
```
Notice how the results aren't always monotonically increasing. After
this patch:
```
+344
+416
+488
+560
+632
+704
+776
+848
+920
+992
+1064
+1136
+1208
+1280
+1352
+1424
+1496
+1568
+1640
+1712
+1784
+1856
+1928
+2000
+2072
+2144
```
Reviewers: hvr, erikd, simonmar, jrtc27, trommler
Reviewed By: simonmar
Subscribers: trommler, jrtc27, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing internal counters:
* gc_alloc_block_sync
* whitehole_spin
* gen[g].sync
* gen[1].sync
are now not shown in the -s report unless --internal-counters is also passed.
If --internal-counters is passed we now show the counters above, reformatted, as
well as several other counters. In particular, we now count the yieldThread()
calls that SpinLocks do as well as their spins.
The added counters are:
* gc_spin (spin and yield)
* mut_spin (spin and yield)
* whitehole_threadPaused (spin only)
* whitehole_executeMessage (spin only)
* whitehole_lockClosure (spin only)
* waitForGcThreadsd (spin and yield)
As well as the following, which are not SpinLock-like things:
* any_work
* do_work
* scav_find_work
See the Note for descriptions of what these counters are.
We add busy_wait_nops in these loops along with the counter increment where it
was absent.
Old internal counters output:
```
gc_alloc_block_sync: 0
whitehole_gc_spin: 0
gen[0].sync: 0
gen[1].sync: 0
```
New internal counters output:
```
Internal Counters:
Spins Yields
gc_alloc_block_sync 323 0
gc_spin 9016713 752
mut_spin 57360944 47716
whitehole_gc 0 n/a
whitehole_threadPaused 0 n/a
whitehole_executeMessage 0 n/a
whitehole_lockClosure 0 0
waitForGcThreads 2 415
gen[0].sync 6 0
gen[1].sync 1 0
any_work 2017
no_work 2014
scav_find_work 1004
```
Test Plan:
./validate
Check it builds with #define PROF_SPIN removed from includes/rts/Config.h
Reviewers: bgamari, erikd, simonmar, hvr
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #3553, #9221
Differential Revision: https://phabricator.haskell.org/D4302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unreg build failed as:
$ ./configure --enable-unregisterised
$ make
HC [stage 1] libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o
ghc_1.hc: In function 'ghczmprim_GHCziPrimopWrappers_pdep8zh_entry':
ghc_1.hc:1810:9: error:
error: implicit declaration of function 'hs_pdep8'; did you mean 'hs_ctz8'?
[-Werror=implicit-function-declaration]
_c3jz = hs_pdep8(*Sp, Sp[1]);
^~~~~~~~
hs_ctz8
|
1810 | _c3jz = hs_pdep8(*Sp, Sp[1]);
| ^
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: See definition of PRINTF above the change
Reviewers: bgamari, erikd, simonmar, Phyx
Reviewed By: Phyx
Subscribers: Phyx, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4392
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4374
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents the register being picked up as a scratch register.
Otherwise the allocator would be free to use it before a call. This
fixes #14619.
Test Plan: ci, repro case on #14619
Reviewers: bgamari, Phyx, erikd, simonmar, RyanGlScott, simonpj
Reviewed By: Phyx, RyanGlScott, simonpj
Subscribers: simonpj, RyanGlScott, Phyx, rwbarton, thomie, carter
GHC Trac Issues: #14619
Differential Revision: https://phabricator.haskell.org/D4348
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows we use the function `win32AllocStack` to do stack
allocations in 4k blocks and insert a stack check afterwards
to ensure the allocation returned a valid block.
The problem is this function does something that by C semantics
is pointless. The stack allocated value can never escape the
function, and the stack isn't used so the compiler just optimizes
away the entire function body.
After considering a bunch of other possibilities I think the simplest
fix is to just disable optimizations for the function.
Alternatively inline assembly is an option but the stack check function
doesn't have a very portable name as it relies on e.g. `libgcc`.
Thanks to Sergey Vinokurov for helping diagnose and test.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14669
Differential Revision: https://phabricator.haskell.org/D4343
|
|
|
|
| |
This reverts commit a1a689dda48113f3735834350fb562bb1927a633.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
get/setAllocationCounter didn't take into account allocations in the
current block. This was known at the time, but it turns out to be
important to have more accuracy when using these in a fine-grained
way.
Test Plan:
New unit test to test incrementally larger allocaitons. Before I got
results like this:
```
+0
+0
+0
+0
+0
+4096
+0
+0
+0
+0
+0
+4064
+0
+0
+4088
+4056
+0
+0
+0
+4088
+4096
+4056
+4096
```
Notice how the results aren't always monotonically increasing. After
this patch:
```
+344
+416
+488
+560
+632
+704
+776
+848
+920
+992
+1064
+1136
+1208
+1280
+1352
+1424
+1496
+1568
+1640
+1712
+1784
+1856
+1928
+2000
+2072
+2144
```
Reviewers: niteria, bgamari, hvr, erikd
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4288
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
GHC Trac Issues: #14513
Differential Revision: https://phabricator.haskell.org/D4226
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4194
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GC sync is the time between a GC being intiated and all the mutator
threads finally stopping so that the GC can start. Problems that cause
the GC sync to be delayed are hard to find and can cause dramatic
slowdowns for heavily parallel programs.
The new flag --long-gc-sync=<time> helps by emitting a warning and
calling a user-overridable hook when the GC sync time exceeds the
specified threshold. A debugger can be used to set a breakpoint when
this happens and inspect the stacks of threads to find the culprit.
Test Plan:
```
$ ./inplace/bin/ghc-stage2 +RTS --long-gc-sync=0.0000001 -S
Alloc Copied Live GC GC TOT TOT Page Flts
bytes bytes bytes user elap user elap
1135856 51144 153736 0.000 0.000 0.002 0.002 0 0 (Gen: 0)
1034760 94704 188752 0.000 0.000 0.002 0.002 0 0 (Gen: 0)
1038888 134832 228888 0.009 0.009 0.011 0.011 0 0 (Gen: 1)
1025288 90128 235184 0.000 0.000 0.012 0.012 0 0 (Gen: 0)
1049088 130080 333984 0.000 0.000 0.013 0.013 0 0 (Gen: 0)
Warning: waited 0us for GC sync
1034424 73360 331976 0.000 0.000 0.013 0.013 0 0 (Gen: 0)
```
Also tested on a real production problem.
Reviewers: niteria, bgamari, erikd
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4193
|
|
|
|
|
|
|
| |
These removes left-overs from e3ba26f8b49700b41ff4672f3f7f6a4e453acdcc
where I implemented `compareByteArray#` as an out-of-line primop, which
got optimised into an inline primop shortly afterwards
(as per 7673561555ae354fd9eed8de1e57c681906e2d49).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is another step for fixing #13825 and is based on D38 by Simon
Marlow.
The change allows storing multiple constructor fields within the same
word. This currently applies only to `Float`s, e.g.,
```
data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Float
```
on 64-bit arch, will now store both fields within the same constructor
word. For `WordX/IntX` we'll need to introduce new primop types.
Main changes:
- We now use sizes in bytes when we compute the offsets for
constructor fields in `StgCmmLayout` and introduce padding if
necessary (word-sized fields are still word-aligned)
- `ByteCodeGen` had to be updated to correctly construct the data
types. This required some new bytecode instructions to allow pushing
things that are not full words onto the stack (and updating
`Interpreter.c`). Note that we only use the packed stuff when
constructing data types (i.e., for `PACK`), in all other cases the
behavior should not change.
- `RtClosureInspect` was changed to handle the new layout when
extracting subterms. This seems to be used by things like `:print`.
I've also added a test for this.
- I deviated slightly from Simon's approach and use `PrimRep` instead
of `ArgRep` for computing the size of fields. This seemed more
natural and in the future we'll probably want to introduce new
primitive types (e.g., `Int8#`) and `PrimRep` seems like a better
place to do that (where we already have `Int64Rep` for example).
`ArgRep` on the other hand seems to be more focused on calling
functions.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Test Plan: ./validate
Reviewers: bgamari, simonmar, austin, hvr, goldfire, erikd
Reviewed By: bgamari
Subscribers: maoe, rwbarton, thomie
GHC Trac Issues: #13825
Differential Revision: https://phabricator.haskell.org/D3809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds the ability to generate stack traces on crashes for Windows.
When running in the interpreter this attempts to use symbol information from
the interpreter and information we know about the loaded object files to
resolve addresses to symbols.
When running compiled it doesn't have this information and then defaults
to using symbol information from PDB files. Which for now means only
files compiled with ICC or MSVC will show traces compiled.
But I have a future patch that may address this shortcoming.
Also since I don't know how to walk a pure haskell stack, I can for now
only show the last entry. I'm hoping to figure out how Apply.cmm works to
be able to walk the stalk and give more entries for pure haskell code.
In GHCi
```
$ echo main | inplace/bin/ghc-stage2.exe --interactive ./testsuite/tests/rts/derefnull.hs
GHCi, version 8.3.20170830: http://www.haskell.org/ghc/ :? for help
Ok, 1 module loaded.
Prelude Main>
Access violation in generated code when reading 0x0
Attempting to reconstruct a stack trace...
Frame Code address
* 0x77cde10 0xc370229 E:\..\base\dist-install\build\HSbase-4.10.0.0.o+0x190031
(base_ForeignziStorable_zdfStorableInt4_info+0x3f)
```
and compiled
```
Access violation in generated code when reading 0x0
Attempting to reconstruct a stack trace...
Frame Code address
* 0xf0dbd0 0x40bb01 E:\..\rts\derefnull.run\derefnull.exe+0xbb01
```
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new primop
compareByteArrays# :: ByteArray# -> Int# {- offset -}
-> ByteArray# -> Int# {- offset -}
-> Int# {- length -}
-> Int#
allows to compare the subrange of the first `ByteArray#` to
the (same-length) subrange of the second `ByteArray#` and returns a
value less than, equal to, or greater than zero if the range is found,
respectively, to be byte-wise lexicographically less than, to match,
or be greater than the second range.
Under the hood, the new primop is implemented in terms of the standard
ISO C `memcmp(3)` function. It is currently an out-of-line primop but
work is underway to optimise this into an inline primop for a future
follow-up Differential (see D4091).
This primop has applications in packages like `text`, `text-short`,
`bytestring`, `text-containers`, `primitive`, etc. which currently
have to incur the overhead of an ordinary FFI call to directly or
indirectly invoke `memcmp(3)` as well has having to deal with some
`unsafePerformIO`-variant.
While at it, this also improves the documentation for the existing
`copyByteArray#` primitive which has a non-trivial type-signature
that significantly benefits from a more explicit description of its
arguments.
Reviewed By: bgamari
Differential Revision: https://phabricator.haskell.org/D4090
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's often hard to debug things like segfaults on Windows,
mostly because gdb isn't always of use and users don't know
how to effectively use it.
This patch provides a way to create a crash drump by passing
`+RTS --generate-crash-dumps` as an option. If any unhandled
exception is triggered a dump is made that contains enough
information to be able to diagnose things successfully.
Currently the created dumps are a bit big because I include
all registers, code and threads information.
This looks like
```
$ testsuite/tests/rts/derefnull.run/derefnull.exe +RTS
--generate-crash-dumps
Access violation in generated code when reading 0000000000000000
Crash dump created. Dump written to:
E:\msys64\tmp\ghc-20170901-220250-11216-16628.dmp
```
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari, simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3912
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exception handling on Windows is unfortunately a bit complicated.
But essentially the VEH Handlers we currently have are running too
early.
This was a problem as it ran so early it also swallowed C++ exceptions
and other software exceptions which the system could have very well
recovered from.
So instead we use a sequence of chains to for the exception handlers to
run as late as possible. You really can't get any later than this.
Please read the comment in the patch for more details.
I'm also providing a switch to allow people to turn off the exception
handling entirely. In case it does present a problem with their code.
(Reverted and recommitted to fix authorship information)
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
GHC Trac Issues: #13911, #12110
Differential Revision: https://phabricator.haskell.org/D3911
|
|
|
|
|
|
| |
Reverting to fix authorship of commit.
This reverts commit 1825cbdbdf08ed4bd6fd6794852596078953298a.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate, add tests
Reviewers: simonmar, austin, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exception handling on Windows is unfortunately a bit complicated.
But essentially the VEH Handlers we currently have are running too
early.
This was a problem as it ran so early it also swallowed C++ exceptions
and other software exceptions which the system could have very well
recovered from.
So instead we use a sequence of chains to for the exception handlers to
run as late as possible. You really can't get any later than this.
Please read the comment in the patch for more details.
I'm also providing a switch to allow people to turn off the exception
handling entirely. In case it does present a problem with their code.
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
GHC Trac Issues: #13911, #12110
Differential Revision: https://phabricator.haskell.org/D3911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done by reusing the existing cross-platform
`getProcessElapsedTime()` function, which already provides nanosecond
monotonic clocks, and fallback for platforms that don't have those.
To do this, `getProcessElapsedTime()` had to be moved from a private RTS
symbol into the public interface.
Accuracy is improved in 2 ways:
* Use of the monotonic clock where available
* Measuring the total time spent waiting instead of a sum
of intervals (between which there are small gaps)
Reviewers: bgamari, austin, hvr, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
orzo in `#ghc` reported seeing a crash due to the retainer profiler encountering
a BLOCKING_QUEUE closure, which isRetainer didn't know about. I performed an
audit to make sure that all of the valid closure types were listed; they
weren't. This is my guess of how they should appear.
Test Plan: Validate
Reviewers: simonmar, austin, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie
GHC Trac Issues: #14235
Differential Revision: https://phabricator.haskell.org/D3967
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a function to the RTS linker API which lets the
user check the status of dynamically linked objects.
It was initially proposed by @afarmer in D2068.
It's useful for testing the linker and also for detecting retention
problems in production.
It takes a path, because it's easier to use path as key instead of producing
some stable handle.
It returns an enum instead of bool, because I see no reason for destroying
information. All the complexity is already out in the open, so there's
nothing to save the users from.
Test Plan: ./validate
Reviewers: simonmar, Phyx, bgamari, austin, erikd
Reviewed By: Phyx, bgamari
Subscribers: rwbarton, afarmer, thomie
Differential Revision: https://phabricator.haskell.org/D3963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This sprintf is safe thanks to the guarantees on the format strings that
we pass to it. Well, almost. The GR_FILENAME_FMT_GUM format would not
have satisfied them if it was still used.
If someone makes a mistake that's a potential privilege escalation,
so I think it's reasonable to switch to snprintf to protect against
that remote possibility.
Test Plan: it builds, CI
Reviewers: simonmar, bgamari, austin, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3944
|
|
|
|
|
|
|
|
|
|
| |
This trailing comma snuck in in a recent patch. There is nothing wrong with the
comma; it's perfectly valid C99, yet nevertheless Mac OS X's dtrace utility
chokes on it with,
dtrace: failed to compile script rts/RtsProbes.d:
"includes/rts/EventLogFormat.h", line 245: syntax error near "}"
make[1]: *** [rts/dist/build/RtsProbes.h] Error 1
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Build, program with `-eventlog`, try running with `+RTS -h`
Reviewers: austin, erikd, simonmar
Subscribers: rwbarton, thomie
GHC Trac Issues: #14096
Differential Revision: https://phabricator.haskell.org/D3922
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, erikd, simonmar
Subscribers: rwbarton, thomie
GHC Trac Issues: #14096
Differential Revision: https://phabricator.haskell.org/D3923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here we encode the cost centre list as static data. This means that the
initialization stubs are small functions which should be easy for GCC to
compile, even with optimization.
Fixes #7960.
Test Plan: Test profiling
Reviewers: austin, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie
GHC Trac Issues: #7960
Differential Revision: https://phabricator.haskell.org/D3853
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These ignore commandline arguments for ignore and commandline as well as
GHCRTS arguments for ignoreAll. Passing RTS flags given on the command
line along to the program by simply skipping processing of these flags
by the RTS.
This fixes #12870.
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: Phyx, rwbarton, thomie
GHC Trac Issues: #12870
Differential Revision: https://phabricator.haskell.org/D3740
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Get utf8 encoded arguments before we call hs_init and use them
instead of ignoring hs_init arguments. This reduces differing
behaviour of the RTS between windows and linux and simplifies
the code involved.
A few testcases were changed to expect the same result on windows
as on linux after the changes.
This fixes #13940.
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar, Phyx
Subscribers: Phyx, rwbarton, thomie
GHC Trac Issues: #13940
Differential Revision: https://phabricator.haskell.org/D3739
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An additional stat is tracked per gc: par_balanced_copied This is the
the number of bytes copied by each gc thread under the balanced lmit,
which is simply (copied_bytes / num_gc_threads). The stat is added to
all the appropriate GC structures, so is visible in the eventlog and in
GHC.Stats.
A note is added explaining how work balance is computed.
Remove some end of line whitespace
Test Plan:
./validate
experiment with the program attached to the ticket
examine code changes carefully
Reviewers: simonmar, austin, hvr, bgamari, erikd
Reviewed By: simonmar
Subscribers: Phyx, rwbarton, thomie
GHC Trac Issues: #13830
Differential Revision: https://phabricator.haskell.org/D3658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The problem occurred when
* Threads A & B evaluate the same thunk
* Thread A context-switches, so the thunk gets blackholed
* Thread C enters the blackhole, creates a BLOCKING_QUEUE attached to
the blackhole and thread A's `tso->bq` queue
* Thread B updates the blackhole with a value, overwriting the BLOCKING_QUEUE
* We GC, replacing A's update frame with stg_enter_checkbh
* Throw an exception in A, which ignores the stg_enter_checkbh frame
Now we have C blocked on A's tso->bq queue, but we forgot to check the
queue because the stg_enter_checkbh frame has been thrown away by the
exception.
The solution and alternative designs are discussed in Note [upd-black-hole].
This also exposed a bug in the interpreter, whereby we were sometimes
context-switching without calling `threadPaused()`. I've fixed this
and added some Notes.
Test Plan:
* `cd testsuite/tests/concurrent && make slow`
* validate
Reviewers: niteria, bgamari, austin, erikd
Reviewed By: erikd
Subscribers: rwbarton, thomie
GHC Trac Issues: #13751
Differential Revision: https://phabricator.haskell.org/D3630
|
|
|
|
| |
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
| |
Our new CPP linter enforces this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C code in the RTS now gets built with `-Wundef` and the Haskell code
(stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever
`#if` is used on undefined identifiers.
Test Plan: Validate on Linux and Windows
Reviewers: austin, angerman, simonmar, bgamari, Phyx
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While looking at #13615 I noticed that there was this strange open-coded
memcpy in the definition of the cloneArray macro. I don't see why this
should be preferable to memcpy.
Test Plan: Validate, particularly focusing on array operations
Reviewers: simonmar, tibbe, austin, alexbiehl
Reviewed By: tibbe, alexbiehl
Subscribers: alexbiehl, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider one-line module
module B (v) where v = "hello"
in -fvia-C mode it generates code like
static char gibberish_str[] = "hello";
It resides in data section (precious resource on ia64!).
The patch switches genrator to emit:
static const char gibberish_str[] = "hello";
Other types if symbols that gained 'const' qualifier are:
- info tables (from haskell and CMM)
- static reference tables (from haskell and CMM)
Cleanups along the way:
- fixed info tables defined in .cmm to reside in .rodata
- split out closure declaration into 'IC_' / 'EC_'
- added label declaration (based on label type) right before
each label definition (based on section type) so that C
compiler could check if declaration and definition matches
at definition site.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: ran testsuite on unregisterised x86_64 compiler
Reviewers: simonmar, ezyang, austin, bgamari, erikd
Reviewed By: bgamari, erikd
Subscribers: rwbarton, thomie
GHC Trac Issues: #8996
Differential Revision: https://phabricator.haskell.org/D3481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This both says what we mean and silences a bunch of spurious CPP linting
warnings. This pragma is supported by all CPP implementations which we
support.
Reviewers: austin, erikd, simonmar, hvr
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3482
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before ghc-7.2 hs_add_root() had to be used to initialize haskell
modules when haskell was called from FFI.
commit a52ff7619e8b7d74a9d933d922eeea49f580bca8
("Change the way module initialisation is done (#3252, #4417)")
removed needs for hs_add_root() and made function a no-op.
For backward compatibility '__stginit_<module>' symbol was
not removed.
This change removes no-op hs_add_root() function and unused
'__stginit_<module>' symbol from each haskell module.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: ./validate
Reviewers: simonmar, austin, bgamari, erikd
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3460
|
|
|
|
| |
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
| |
This is causing too much platform dependent breakage at the moment. We
will need a more rigorous testing strategy before this can be
merged again.
This reverts commit 7e340c2bbf4a56959bd1e95cdd1cfdb2b7e537c2.
|
|
|
|
| |
These were missed in D3278.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C code in the RTS now gets built with `-Wundef` and the Haskell code
(stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever
`#if` is used on undefined identifiers.
Test Plan: Validate on Linux and Windows
Reviewers: austin, angerman, simonmar, bgamari, Phyx
Reviewed By: bgamari
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we throw an exception for heap overflow, we should only print
the heap overflow message in the main thread when the HeapOverflow
exception is caught, rather than as a side effect in the GC.
Stack overflows were already done this way, I just made heap overflow
consistent with stack overflow, and did some related cleanup.
Fixes broken T2592(profasm) which was reporting the heap overflow
message twice (you would only notice when building with profiling
libs enabled).
Test Plan: validate
Reviewers: bgamari, niteria, austin, DemiMarie, hvr, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3394
|