# Copyright (C) 2019 MariaDB corporation Ab. All rights reserved. Use # is subject to license terms. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 # USA use GenTest::Grammar; # Configuration file template for using rqg_batch.pl for simplifying RQG tests # # Please # - Copy this file to for example 1.cfg and # - Adjust the settings so that they fit to your use case and environment. # # # Anything which is relevant for the simplification process itself # == lib/Simplify.pm needs to know that # must or should be on top level and not nested into 'rqg_options'. # { # desired_status_codes #--------------------- # Lists of # desired results --> whitelist_* # unwanted results --> blacklist_* # RQG exit statuses --> *_statuses # text patterns in RQG log --> *_patterns # which allow RQG tools to make a verdict if some RQG run replayed # the result defined by that or not. # What counts here is getting # Auxiliary::RQG_VERDICT_REPLAY ('replay') # which means we had a whitelist match (in minimum one element per list) # and no blacklist match (no element of the two lists). # # Regarding statuses: # The complete list of statuses is in lib/GenTest/Constants.pm. # Just the most important ones: # STATUS_SERVER_DEADLOCKED STATUS_REPLICATION_FAILURE # STATUS_VALGRIND_FAILURE STATUS_BACKUP_FAILURE # STATUS_RECOVERY_FAILURE STATUS_ENVIRONMENT_FAILURE # STATUS_ALARM(RQG core sees problem but has no idea why) # STATUS_SERVER_CRASHED STATUS_DATABASE_CORRUPTION # STATUS_ANY_ERROR(any status != STATUS_OK) # We do no more take the exit status of the process running RQG because of technical reasons. # The status is taken from a line containing # 'RESULT: The RQG run ended with status ' # and written direct after finishing GenTest into the log of the RQG run. # # Regarding text patterns: # The search patterns are often derived from a backtrace found in the log of some # historic RQG run. # Example: # Starting point is a crash of a server which was compiled with debug. # A text patterns could match a group of lines. # white_list_patterns => # [ # "'assert.{0,150}safe_cond_timedwait.{0,150}thr_mutex\.c.{0,50}Item_func_sleep::val_int.{0,3000}SELECT 1,SLEEP\(10\)'" # ]; # # Please be careful when using # - characters with special meaning in pattern matching like +?.*^$()[]{}|\ # Use '\' in order to disable the special meaning or just replace any suspicious character # by a '.' in case the pattern is already selective enough. # - memory addresses or source code line numbers # They are brilliant selective but might stop to work after the next pull source + compile. # # Main purposes of the blacklists during grammar simplification: # 1. When going with some "unsharp" whitelists like (logically) # "I do not care for which assert we simplify first as long its an assert # (and not STATUS_SERVER_DEADLOCKED) ..." # than the simplifier might finally focus on some open bug (assert too) where we already # have a nice replay testcase. So starting at some point of time withn the simplification # process we might just waste resources till end of the simplifier run. # In case the "unsharp" whitelist setting Good blacklists and whitelists could avoid that. # 2. At least some RQG tools collect and preserve any RQG test results which are not what we are # focused on but at least of interest. # Example: # We have some "sharp" whitelists focusing on assert Y only but have just hit assert Z. # In case assert Z is some open bug where we already have a nice replay testcase than preserving # the remainings wastes resources like CPU and IO at least temporary and storage space on disk # for a longer timespan. Good blacklists ... # # whitelist_statuses => [ # 'STATUS_ANY_ERROR', 'STATUS_SERVER_CRASHED', ], whitelist_patterns => [ # mysqld: /home/mleich/work/10.4/storage/innobase/lock/lock0lock.cc:5458: my_bool lock_rec_other_trx_holds_expl_callback(rw_trx_hash_element_t*, lock_rec_other_trx_holds_expl_arg*): Assertion `!expl_lock || expl_lock->trx == arg->impl_trx' failed. # 'mysqld: .{1,150}lock0lock.cc.{1,20} my_bool lock_rec_other_trx_holds_expl_callback.{1,150}: Assertion .\!expl_lock \|\| expl_lock->trx == arg->impl_trx. failed.', # 'mysqld.{1,150}row0sel.cc.{1,20} dberr_t row_sel_get_clust_rec_for_mysql.{1,250} Assertion .0. failed', 'mysqld:.{1,200}dict0dict.ic:.{1,30}dict_index_get_nth_field.{1,500} Assertion .pos < index->n_def. failed', 'SUMMARY: AddressSanitizer: ', # 'mysqld:.{1,150}innobase.{1,1000} Assertion .{1,500} failed.', ], blacklist_statuses => [ 'STATUS_OK', 'STATUS_SERVER_DEADLOCKED', ], blacklist_patterns => [ # https://jira.mariadb.org/browse/MDEV-20048 # mysqld: /home/mleich/work/10.4/storage/innobase/include/data0data.h:621: dfield_t* dtuple_get_nth_field(dtuple_t*, ulint): Assertion `n < tuple->n_fields' failed. 'mysqld: .{1,150}data0data.h:.{1,20} dfield_t. dtuple_get_nth_field.{1,30}: Assertion .n < tuple->n_fields. failed.', # https://jira.mariadb.org/browse/MDEV-17844 # [Draft] Assertion `ulint(rec) == offsets[2]' failed in rec_offs_validate 'mysqld:.{1,100}rem0rec.cc:.{1,30}bool rec_offs_validate.{1,500} failed', # https://jira.mariadb.org/browse/MDEV-20038 # Draft: Assertion `rw_lock_own(dict_index_get_lock(index), RW_LOCK_S)' failed. in btr_cur_search_to_nth_level_func # mysqld: /home/mleich/work/10.4/storage/innobase/btr/btr0cur.cc:1444: dberr_t btr_cur_search_to_nth_level_func(dict_index_t*, ulint, const dtuple_t*, page_cur_mode_t, ulint, btr_cur_t*, rw_lock_t*, const char*, unsigned int, mtr_t*, ib_uint64_t): Assertion `rw_lock_own(dict_index_get_lock(index), RW_LOCK_S)' failed. 'mysqld:.{1,200}btr0cur.cc:.{1,30}dberr_t btr_cur_search_to_nth_level_func.{1,500} failed', # 2019-07-10T14:12:18 [292830] | InnoDB: Failing assertion: !cursor->index->is_committed() 'InnoDB: Failing assertion: \!cursor->index->is_committed\(\)', # RQG runs showing this pattern end usually with the status # STATUS_ENVIRONMENT_FAILURE(110). In case its a grammar maintained by hand than the # grammar is faulty and should be corrected. # But grammar simplification and also grammar masking run some automatic mangling of # grammars which could lead to the same effect because of non avoidable and harmless # reason. So we throw the remainings of such runs away and save by that resources. 'Possible endless loop in grammar.', # # Grammars could have the unfortunate runtime property to cause some dramatic growth # of storage space consumption. This is especially valid in case of grammars generated # during simplification. # Example: All DROPs and DELETEs were shrinked away. # Some typical outcome is: # The server asserts, threads and/or periodic reporters exit with (hopefully) # STATUS_SERVER_CRASHED, the reporter Backtrace prints content of the server error log # and lets some debugger analyze the core file and than RQG exits with (again hopefully) # STATUS_SERVER_CRASHED. # Than in case of some "unsharp" setup of the whitelists (statuses == STATUS_ANY_ERROR, # patterns empty) that all gets valuated as replay. # But its either # - (most likely) a replay of some known "natural" effect which is not a defect # or # - (quite unlikely) the replay of a defect but the surviving data are not sufficient # for analysis and we should better not waste time on that. # Conclusion: # Runs where we hit trouble with storage space are "unwanted". # Server error log pattern: ..... (Error 28 is OS: No space left on device) # [ERROR] InnoDB: preallocating 12582912 bytes for file ./test/#sql-1f36d_10.ibd failed with error 28 # [ERROR] InnoDB: preallocating 65536 bytes for file ./test/FTS_0000000000000524_00000000000005f9_INDEX_5.ibd failed with error 28 '\[ERROR\] InnoDB: preallocating .{1,120} with error 28', # Debugger output pattern: # BFD: Warning: is truncated: expected core file size >= 959647744, found: 55398400. ' is truncated: expected core file size ', ], # simplify_chain defines which test simplification steps/phases should be executed and # in which order. simplify_chain => [ #### PHASE_FIRST_REPLAY #### # Attempt to replay with the compactified initial grammar. # Main purpose: # Check if the whitelist/blacklist statuses/patterns fit because otherwise the # simplification run is valueless. No replay within $trial finished attempts leads to # abort of simplification process. # In case you are believing (*) that the list setup is good # - than you can save some (usually a few minutes up till 0.5h (**)) of the total # simplifier runtime by omitting this phase. # - and fear that $trials might be too small for replaying and also hesitate to # increase $trials from whatever reason than omitting this phase gives you # roughly endless trials on different minimal simplified grammars. # Default: 'first_replay' enabled and first phase. 'first_replay', # #### PHASE_THREAD1_REPLAY #### # Attempt to replay with the actual best (usually the compactified initial) grammar # and threads = 1. # Main purpose: # Check if the desired outcome might be a single user effect. # If yes we can # - apply some simplifications depending on grammar content # ==> reduce complexity # ==> (hopefully) speedup of simplification process which maybe follows # or # - also bail out (corresponding functionality is currently missing). # ==> Setup (manually) mysqltest simplification and start that. # mysqltest simplification is usually serious faster but the manual setup costs # frequent serious efforts. # In case you are believing (*) that its a concurrency problem than you can save some # (usually a few minutes up till 0.5h (**)) of the total simplifier runtime by # omitting this phase. # Default: 'thread1_replay' enabled and second phase. # 'thread1_replay', # #### PHASE_RVT_SIMP #### # Attempt to shrink the amount of reporters, validators, transformers. # Main purpose: # Reduce complexity and (hopefully) speedup of simplification process which maybe follows. # In case you are believing (*) that the reporters, validators, transformers used are # either required or do not consume significant runtime than you can save some # (usually a few minutes up till 1h (**)) of the total simplifier runtime by # omitting this phase. # Default: 'rvt_simp' enabled and third phase. # 'rvt_simp', # #### PHASE_GRAMMAR_SIMP #### # Attempt to shrink (remove components of grammar rules, inline rules etc.) the actual best # replaying grammar. It is never tried to replace the last component of a rule by an empty # string. == We do not take the risk to maybe change the semantics of the test. # Main purpose: # Reduce complexity and (hopefully) speedup of simplification process which maybe follows. # Default: 'grammar_simp' enabled and fourth phase. # 'grammar_simp', #### PHASE_GRAMMAR_DEST #### (Alternative to PHASE_GRAMMAR_SIMP) # Like 'grammar_simp' but it is also tried to replace the last component of a rule by an # empty string. == We take the risk to maybe change the semantics of the test. # Typical use case: # We simplify for a server crash caused by the server itself. # Example: The server asserts when having to execute certain SQL in some situation. # Compared to PHASE_GRAMMAR_SIMP: # - In case some rule consisting of n > 1 unique components could be shrinked to an # empty string only than we might save up till n - 1 RQG runs. # - We will get up till number of valid rules additional RQG runs per campaign. # - In case the components of a top level rule like query could be replaced by the # empty string than the final replay becomes faster and its becomes more obvious that # the root of the bad outcome is most probably before YY grammar processing. # Examples of contra indications: # - We have queries consisting of several SQLs followed by validation. # PHASE_GRAMMAR_DEST might destruct one or more of these SQLs and than we might get # false positives if the validator is not prepared for that case. # - Threads maintain entries in some table and kill each other. # In case that maintenance is partial harmed than the replay likelihood could # decrease drastic. # - Partially surprising uncomfortable effects during manual grammar simplification later. # Default: 'grammar_dest' not enabled. 'grammar_dest', # #### PHASE_GRAMMAR_CLONE ### # Attempt to transform the grammar by cloning of more than once used rules. # Example: # Original grammar =========> Transformed grammar # rule1: rule1: # SELECT where | SELECT __clone_1 | # UPDATE where ; UPDATE __clone_2 ; # where: __clone_1: # WHERE col1 = 2 | WHERE col1 = 2 | # WHERE col2 BETWEEN 3 AND 7; WHERE col2 BETWEEN 3 AND 7; # __clone_2: # WHERE col1 = 2 | # WHERE col2 BETWEEN 3 AND 7; # # In case that is leading to some grammar which differs from the current best one than # grammar simplification is tried (Repetition of PHASE_GRAMMAR_SIMP described above.) # Main purpose: # Reduce complexity and (hopefully) speedup of simplification process which maybe follows. # Default: 'grammar_clone enabled and fifth phase. # 'grammar_clone', #### PHASE_FINAL_REPLAY #### # Attempt to replay with the final simplified test. # Main purpose: # Check how fast some replay could be achieved with that setup and YY grammar. # Default: 'final_replay' enabled and sixth phase. 'final_replay' # (*) Its not that likely that mistakes have a dramatic bad impact. # (**) The time range mentioned is nothing else than some qualified guess based on # experiences. The range depends on $trials, $parallel, how likely the effect you # are simplifying for shows up etc. # At runtime its quite often like # - Saving a few hours looks on the first view impressing but the total simplification # runtime was even without that more than 30 hours. So the win is often <= 10%. # - If partially manual working on some already automatic simplified test including # "active" waiting for results omitting no more necessary simplification steps # could be some serious win or makes you at least a bit happy. # ], # grammar_file #------------- # File which should be used as the base for the simplification process. # It should be an "effective" YY grammar == # - grammar + redefine files are already merged/joined # - any masking was already applied # # Recommendation: # Think about setting '--grammar=......' via command line option. grammar => 'conf/mariadb/table_stress_innodb_nocopy.yy', # redefine files #--------------- # Do not set redefine files here or in the rqg_options section because the RQG test simplifer will # ignore them! # threads => 10, queries => 1000000, # duration and duration_adaption # ------------------------------ # duration assigned to some RQG runner like rqg.pl # == Maximum YY grammar processing time. # duration assigned to rqg_batch.pl # == A value used for computing the duration assigned to some RQG run. # Default: 300 seconds duration => 300, # # duration_adaption == which function to use for adapting the duration assigned to RQG runs # # duration_adaption value for duration assigned to the next RQG run started # 'None' duration (here) == No adaption at all. # Have a fifo containing the real (*) YY grammar processing times of the last 10 replaying RQG # runs. (*) If value measured > duration (here) than only charge duration (here). # 'Maximum' Minimum of (duration (here), maximum(fifo)) # 'MaximumMiddle' (duration (here) + maximum(fifo)) / 2 # 'Experimental' Some value computed based on formula for Gaussian distribution (**). # (**) We have definitely not a Gaussian distribution but the formula # delivers quite usable values. # This is the default. duration_adaption => 'Experimental', # Hints about how to speed up especially the simplification process # 1. Add 'None' the the list of reporters and validators in case you are sure that you do not # need stuff added per default. # 2. In case you simplify for whitelist_patterns matching messages written by the server or # other tools # Example: 'InnoDB: Failing assertion: opt_no_lock' # and not for parts of backtraces than use the reporter 'ServerDead' instead of 'Backtrace'. # The gain in simplification speed will be > 50%. # 3. As long as certain open bugs about server freezes are not fixed and frequent used grammars # will replay them frequent please add the reporter # 'Deadlock1', # even if not searching for these freezes. # RQG tests which have no more a chance to replay what you are searching for will get # earlier detected and terminated. reporters => [ 'Deadlock1', 'ErrorLog', 'Backtrace', # 'ServerDead', 'None', ], validators => [ 'None', ], transformers => [ # Do not assign here a 'None'. ], # Do NOT assign basedirs etc. here # rqg_options #------------ # rqg.pl (RQG runner) options which should be used # Warning: # You can define threads, validators etc. also within the RQG option block. # But please be aware that any setting != 0, undef or '' being outside like # - outside of the rqg_options block within the config file # - within the rqg_batch.pl call # will be glued to the end of the final RQG call line and hereby "win". # rqg_options => { # 'noarchiving' will make the complete simplification process significant faster. # Disadvantages: # - You need to rerun the RQG test later with replay of desired outcome in order to get # the corresponding archive containing a core, content of server datadir etc. # This is most probably only a small extra work because simplified tests replay than # usually faster. # - You also need to rerun the test for outcomes with the verdict 'interest' in case # you are really interested in them. # I recommend to set the next line to comment only if # - having a lot of time or assuming that the simplification will last long anyway # (maybe because the desired outcomes showed up quite rare) # and/or # - going with quite "unsharp" whitelist_patterns so that harvesting several different # bad outcomes seems to be likely. noarchiving => undef, engine => 'InnoDB', gendata => 'conf/mariadb/table_stress.zz', gendata_sql => 'conf/mariadb/table_stress.sql', # rpl_mode # ------------------------------------------- # RQG_RPL_NONE # Run with one server only. No replication of any type at all. rpl_mode => 'none', # # RQG_RPL_STATEMENT # Run with two servers, MariaDB replication and binlog_format=statement. # rpl_mode => 'statement', # RQG_RPL_STATEMENT_NOSYNC # rpl_mode => 'statement-nosync', # # RQG_RPL_MIXED # Run with two servers, MariaDB replication and binlog_format=mixed. # rpl_mode => 'mixed', # RQG_RPL_MIXED_NOSYNC # rpl_mode => 'mixed-nosync', # # RQG_RPL_ROW # Important observation: # 10.4 -> 10.3 failed systematic with Error_code: 1032; handler error HA_ERR_END_OF_FILE # 10.4 -> 10.4 worked # 10.3 -> 10.4 worked # Run with two servers, MariaDB replication and binlog_format=row. # rpl_mode => 'row', # RQG_RPL_ROW_NOSYNC # rpl_mode => 'row-nosync', # # RQG_RPL_GALERA # Unclear if currently used. # Run with n? servers and Galera # rpl_mode => 'galera', # # RQG_RPL_RQG2 # Run with two servers and RQG's builtin statement based replication. # rpl_mode => 'rqg2', # RQG_RPL_RQG3 # Run with three servers and RQG's builtin statement based replication. # rpl_mode => 'rqg3', # sqltracing by RQG # ----------------- # Advantage: # The RQG log content gives you at least some idea which SQL was running when some # replay happened. # Disadvantage: # Higher resource consumption during runtime of the simplifier. # Getting at least some idea which SQL was running when some replay happened isn't bad # but quite frequent such information does not help significant or only a few (the # last ones) statements are already sufficient (== all previous only wasted resources). # I recommend to # - not enable sqltracing here # - perform runs with sqltracing after simplification end if useful at all. # # Print trace message before sending the statement to the server. # sqltrace => undef, # Print trace message after receiving the result or error messages from the server # including error message etc. # sqltrace => 'MarkErrors', mysqld => { 'innodb_adaptive_hash_index' => 'off', # Avoid hitting https://jira.mariadb.org/browse/MDEV-16136 'innodb_stats_persistent' => 'off', # Avoid hitting https://jira.mariadb.org/browse/MDEV-16664 'loose_innodb_lock_schedule_algorithm' => 'fcfs', # # In some environment with many parallel RQG runs the following settings are required # for reducing trouble caused by # - shortages of resources # or # - slow responses of clients and servers. # IMHO it is recommended to set values even if the current defaults are already good # enough. Defaults could ge changed in future and than maybe to some unfortunate # direction. # ====================================================================================== # aio is on most boxes/OS a very short resource. # Disabling its use is usually required and prevents valueless starts of RQG runners and # also other ugly effects to be accepted+already known from that reason. # But this implies that aio related code of InnoDB is not covered. 'loose_innodb_use_native_aio' => 0, # # Threads running the queries from YY grammar might frequent lose their connection # (get killed by other threads or reporters or commit/rollback release) and than need to # 1. connect again # 2. run a few initial SQL's before running the mass of YY grammar queries goes on # And in case 1. or 2. fails the RQG core tends to claim STATUS_SERVER_CRASHED, # STATUS_SERVER_CRASHED, STATUS_ENVIRONMENT_FAILURE and similar. This is often a false # alarm in case the timeouts are too short for some heavy loaded box. # 1. Is often a victim of connection related timeouts. # 2. Is often a victim of locking related timeouts and depending on the functionality # within the RQG core we get either some immediate end of the RQG run with # questionable status or the test goes on but the thread has not done things which # are mandatory for the test to work proper. In the second case we could end up with # false positives and similar. # Per my experience the innodb lock and MDL lock timeouts are quite critical. # In case the threads should use small values for these timeout during YY grammar # processing than these timeouts could be set in the rules # query_connect or # thread_connect # of the YY grammar. # # connect_timeout # Time in seconds that the server waits for a connect packet before returning a # 'Bad handshake'. Increasing may help if clients regularly encounter # 'Lost connection to MySQL server at 'X', system error: error_number' type-errors. # Default: 10 'connect_timeout' => 60, # # net_read_timeout # Time in seconds the server will wait for a client connection to send more data before # aborting the read. # Default: 30 'net_read_timeout' => 30, # # net_write_timeout # Time in seconds to wait on writing a block to a connection before aborting the write. # Default: 60 'net_write_timeout' => 60, # # idle_readonly_transaction_timeout # Time in seconds that the server waits for idle read-only transactions before killing # the connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_readonly_transaction_timeout' => 0, # # idle_transaction_timeout # Time in seconds that the server waits for idle transactions before killing the # connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_transaction_timeout' => 0, # # idle_write_transaction_timeout # Time in seconds that the server waits for idle read-write transactions before killing # the connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_write_transaction_timeout' => 0, # # innodb_lock_wait_timeout # Time in seconds that an InnoDB transaction waits for an InnoDB row lock (not table # lock) before giving up with the error # ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting trans... # When this occurs, the statement (not transaction) is rolled back. The whole # transaction can be rolled back if the innodb_rollback_on_timeout option is used. # Increase this for data warehousing applications or where other long-running operations # are common, or decrease for OLTP and other highly interactive applications. # This setting does not apply to deadlocks, which InnoDB detects immediately, rolling # back a deadlocked transaction. # 0 (from MariaDB 10.3.0) means no wait. See WAIT and NOWAIT. # Default Value: 50 'innodb-lock-wait-timeout' => 50, # # interactive_timeout # Time in seconds that the server waits for an interactive connection (one that connects # with the mysql_real_connect() CLIENT_INTERACTIVE option) to become active before # closing it. # Default Value: 28800 # AFAIK RQG will not initiate such connections. 'interactive_timeout' => 28800, # # lock_wait_timeout # Timeout in seconds for attempts to acquire metadata locks. Statements using metadata # locks include FLUSH TABLES WITH READ LOCK, LOCK TABLES, HANDLER and DML and DDL # operations on tables, stored procedures and functions, and views. The timeout is # separate for each attempt, of which there may be multiple in a single statement. # 0 (from MariaDB 10.3.0) means no wait. See WAIT and NOWAIT. # Default Value: # 86400 (1 day) >= MariaDB 10.2.4 # 31536000 (1 year) <= MariaDB 10.2.3 'lock-wait-timeout' => 86400, # # table_lock_wait_timeout # Unused, and removed in MariaDB/MySQL 5.5.3 # Default Value: 50 # IMHO its better to set it because we do not know which MariaDB version RQG might meet. 'loose-table_lock_wait_timeout' => 50, # # wait_timeout # Time in seconds that the server waits for a connection to become active before # closing it. The session value is initialized when a thread starts up from either the # global value, if the connection is non-interactive, or from the interactive_timeout # value, if the connection is interactive. # Default Value: 28800 'wait_timeout' => 28800, # # slave_net_timeout # Time in seconds for the slave to wait for more data from the master before considering # the connection broken, after which it will abort the read and attempt to reconnect. # The retry interval is determined by the MASTER_CONNECT_RETRY open for the # CHANGE MASTER statement, while the maximum number of reconnection attempts is set by # the master-retry-count variable. # The first reconnect attempt takes place immediately. # Default Value: # 60 (1 minute) (>= MariaDB 10.2.4) # 3600 (1 hour) (<= MariaDB 10.2.3) 'slave_net_timeout' => 60, # # # This makes the simplification process faster. 'log-output' => 'none', }, }, # grammar_flags #-------------- # You could set "grammar_flags" to GRAMMAR_FLAG_COMPACT_RULES so that rules such as # rule: a | a | a | a | a | a | b ; are compressed to rule: a | b # before simplification. # The impact of that at test runtime is # Known (irrelevant up till big) disadvantage of that at grammar runtime # - non compressed: Generation of 86% 'a' and 14% 'b'. # - compressed: Generation of 50% 'a' and 50% 'b'. # regarding # - likelihood to replay some desired outcome # Jumps to the better are possible too but less likely. # - evolution of resource consumption of tests at runtime. # Jumps to the better are possible too but less likely. # The rqg_batch resource control is good in handling that some more and more bigger fraction # of concurrent tests becomes critical regarding resource consumption. # But meeting some 100% of all concurrent tests are critical from the begin on might # - exceed the capabilities of resource control to avoid disasters # - not exceed the capabilities but cause a too high fraction of to be stopped runs # # Impact on the maximum number of shrink attempts: # The old grammar simplifier tried to remove any single component of the grammar rule # --> in maximum two attempts with the compressed rule # --> in maximum seven attempts with the non compressed rule # So GRAMMAR_FLAG_COMPACT_RULES gave often in sum (advantage+disadvantage) some benefit. # # The current (new) grammar simplifier determines the unique components ('a' and 'b') and tries # than to remove all occurence of some unique component. # --> In maximum two attempts including that the disadvantage described above cannot happen. # # Recommendation: # Do NOT set GRAMMAR_FLAG_COMPACT_RULES. Of course feel free to experiment. # # grammar_flags => +GRAMMAR_FLAG_COMPACT_RULES, # trials #------- # Maximum number of finished RQG runs which did not replay before the simplifier gives up # with that simplification phase or the complete process. # # Phase Give up after a queue of finished and non replaying attempts # PHASE_FIRST_REPLAY $trials and abort the simplifier run # PHASE_THREAD1_REPLAY $trials and switch to the next phase # PHASE_FINAL_REPLAY $trials and report that, give summary and exit # # All other simplification phases work roughly "open end" and do not use the value in $threads # at all. # # Given the fact that certain desired outcomes are often not that likely to reproduce even # if the grammar is capable to do it use a value between 30 and 50. trials => 60, # search_var_size #---------------- # Number of bytes (counted from the end of the output file) to be used during # search for expected_output We suck the last "search_var_size" Bytes of the file # to be searched into a variable. # A too huge "search_var_size" could cause problems. # The relevant zone within the file is maybe # - smaller # If our search pattern is unfortunately a bit unspecific and if it # could also occur within irrelevant zones of the file than we might # get false positives. Decreasing "search_var_size" might help. # - bigger # We might get false negatives. Increasing "search_var_size" might # help but I am unsure if any OS and PERL implementation supports # such a monstrous variable. search_var_size => 30000000, # run_id # ------ # run_id can be assigned on cammand line to rqg_batch but it cannot be set in the config file here. # It is mentioned here because it plays an important role in the explanation of the next parameters # 'vardir' and 'workdir'. # rqg_batch.pl itself assigns the number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) # to it. # This roughly guarantees that consecutive runs of # - tools managing batches of RQG runs like rqg_batch.pl # - using the same values for workdir and vardir # will not finally use the same workdirs and vardir for their run. # So collisions during runtime and mangling of historic results should be mostly impossible. # # # vardir #------- # "Server activity" should happen in the "vardir" of the rqg_batch run. # And that gets created as subdirectory of the directory assigned here. # Example: /dev/shm/vardir/ --> /dev/shm/vardir/1545341608 # Important points are: # - free space within the filesystem # - performance of the filesystem # Simplification gets usually a significant speed up if we could use a memory based filesystem # like tmpfs. # # Default: /dev/shm/vardir # vardir => '/dev/shm/vardir', # workdir #--------------- # Grammars, RQG logs etc. of the simplification process get stored within the workdir of the # rqg_batch run/the grammar simplification process. # And that gets created as subdirectory of the directory assigned here. # Example: / --> ./storage/1545341608 # # Default: ./storage # workdir => './storage' }