equal
deleted
inserted
replaced
|
1 ///////////////////////////////////////////// |
|
2 |
|
3 #TLS Out of memory test |
|
4 |
|
5 ///////////////////////////////////////////// |
|
6 [Tlstest] |
|
7 |
|
8 # READ ME! |
|
9 # |
|
10 ### This is the range of values for __UHEAP_FAILNEXT that are tested. |
|
11 ### TLS currently requires 846 heap allocations to make a connection. |
|
12 ### If the test has not passed by MaxFailureThreshold then it fails. |
|
13 ### This is to prevent the test running forever if the network or server is down. |
|
14 # |
|
15 # The above comment is outdated - in 8.0 it passes on the first iteration with 840. |
|
16 # The Comms Framework submission increases the threshold dramatically (as can be seen |
|
17 # below); this is at least substantially due to the new RFileLogger interface since |
|
18 # every single static logging call now makes an allocation (and the TLS client-side |
|
19 # has its own logging subsystem, hence a ten row hexdump becomes ten separate RFileLogger |
|
20 # calls). |
|
21 # Of course to be a strong OOM test the loop should start at one anyway, otherwise there |
|
22 # are many states we're not probing. It is suspected that the reason this is not done is two- |
|
23 # fold: firstly it would take a long time and so mightn't be suitable for routine run and |
|
24 # secondly and importantly the OpenSSL server currently used on the test network does not |
|
25 # handle spontaneous socket disconnection and so would need restarting after many of these |
|
26 # failures. Once a more robust test server is in place this part of the testing needs to be |
|
27 # revisited. |
|
28 |
|
29 FailureThreshold=1 |
|
30 MaxThreshold=3200 |
|
31 IPAddress=192.168.10.11 |
|
32 IPPort=543 |