Warmcat homepage andy@warmcat.com
libwebsockets
{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1752062394, "reponame":"openssl", "desc":"OpenSSL", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://warmcat.com/repo/openssl", "f":3, "items": [ {"schema":"libjg2-1", "cid":"babc50646aeeca5a99824b6b27fc30c8", "commit": {"type":"commit", "time": 1495443930, "time_ofs": 120, "oid_tree": { "oid": "afab2ad82711034c46ad52df26d053fb067ee7a9", "alias": []}, "oid":{ "oid": "a486561b691d6293a901b412172ca0c6d1ffc0dc", "alias": []}, "msg": "test/secmemtest.c: clarify limitations for huge secure memory arena test.", "sig_commit": { "git_time": { "time": 1495443930, "offset": 120 }, "name": "Andy Polyakov", "email": "appro@openssl.org", "md5": "50bd64fa2a792cbbf679fa16213a3b2a" }, "sig_author": { "git_time": { "time": 1495358194, "offset": 120 }, "name": "Andy Polyakov", "email": "appro@openssl.org", "md5": "50bd64fa2a792cbbf679fa16213a3b2a" }}, "body": "test/secmemtest.c: clarify limitations for huge secure memory arena test.\n\nReviewed-by: Rich Salz \u003crsalz@openssl.org\u003e\n" , "diff": "diff --git a/test/secmemtest.c b/test/secmemtest.c\nindex e9be8f3..cb7d1ec 100644\n--- a/test/secmemtest.c\n+++ b/test/secmemtest.c\n@@ -82,18 +82,23 @@ static int test_sec_mem(void)\n *\n * CRYPTO_secure_malloc_init((size_t)1\u003c\u003c34, (size_t)1\u003c\u003c4);\n *\n- * Which really only works on 64-bit systems, and even then the\n- * code attempts to allocate 16 GB secure memory arena. Linux\n- * can deal with this better than other Unixy OS's (e.g. MacOS)\n- * but we don't want to push the system too hard during a unit\n- * test. In addition, trying to allocate 16GB will cause the\n- * mlock() call to fail, so that was at least changed to no\n- * longer be an assert. If the reader of this comment really\n- * wants to make sure that infinite loop is fixed, they can\n- * enable the code below.\n+ * Which really only works on 64-bit systems, since it took 16 GB\n+ * secure memory arena to trigger the problem. It naturally takes\n+ * corresponding amount of available virtual and physical memory\n+ * for test to be feasible/representative. Since we can't assume\n+ * that every system is equipped with that much memory, the test\n+ * remains disabled. If the reader of this comment really wants\n+ * to make sure that infinite loop is fixed, they can enable the\n+ * code below.\n */\n # if 0\n- /* This test should only be run under Linux... runner beware */\n+ /*-\n+ * On Linux and BSD this test has a chance to complete in minimal\n+ * time and with minimum side effects, because mlock is likely to\n+ * fail because of RLIMIT_MEMLOCK, which is customarily [much]\n+ * smaller than 16GB. In other words Linux and BSD users can be\n+ * limited by virtual space alone...\n+ */\n if (sizeof(size_t) \u003e 4) {\n TEST_info(\u0022Possible infinite loop: 1\u003c\u003c31 limit\u0022);\n if (TEST_true(CRYPTO_secure_malloc_init((size_t)1\u003c\u003c34, (size_t)1\u003c\u003c4) !\u003d 0))\n","s":{"c":1752062394,"u": 27703}} ],"g": 28532,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 0, "si": 0, "db":0, "di":0, "sat":0, "lfc": "0000"}