profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/thatsafunnyname/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Peter (Stig) Edwards thatsafunnyname London

thatsafunnyname/check_disk 0

Check disk nagios plugin

thatsafunnyname/dbd-pgpp 0

Pure-Perl PostgreSQL database driver for DBI

thatsafunnyname/DBD-PgPPSjis 0

DBD::PgPPSjis - Pure-Perl DBI driver for (not raw) ShiftJIS

thatsafunnyname/fastcgipp 0

A C++ FastCGI and Web development platform:

thatsafunnyname/go-memcached 0

Memcached library for Go

thatsafunnyname/jshint 0

JSHint is a tool that helps to detect errors and potential problems in your JavaScript code

thatsafunnyname/knielsen-pmp 0

Knielsen's version of poor-mans-profiler based on libunwind

thatsafunnyname/memcached 0

memcached development tree

thatsafunnyname/memcbench 0

Simple multi-threaded memcached benchmarking script, primarily for testing InnoDB-memcached plugin

issue closedfacebook/rocksdb

db_bench -benchmarks fillsync -num 999 triggers floating point exception

Hello and thanks for RocksDB,

I noticed a floating point exception core dump when running:

db_bench -benchmarks fillsync -num 999

Where -num can be any value lower than 1000. I think returning an error would be better.

When the benchmark is fillsync, num_ /= 1000 is performed.

The crash is in rocksdb::Benchmark::KeyGenerator::Next as called from rocksdb::Benchmark::DoWrite as the KeyGenerator has 0 values as it was constructed with num = ( num_ + max_num_range_tombstones_ ) and in this case both are zero.

The crash can be avoided by using -writes and not -num:

  db_bench -benchmarks fillsync -writes 999

as then DoWrite uses writes_ for num_ops and not num_.

A fix for just fillsync looks like this change to tools/db_bench_tool.cc

      } else if (name == "fillsync") {
>>      if (num_ < 1000) {
>>        fprintf(stderr,
>>                "fillsync requires num to be >= 1000\n");
>>        ErrorExit();
>>      }

I can create a pull request with this change, and a similar one for fill100K (also crashes). readrandomsmall also performs reads_ /= 1000 but does not crash.

closed time in 21 days

thatsafunnyname

issue commentfacebook/rocksdb

db_bench -benchmarks fillsync -num 999 triggers floating point exception

Fixed with https://github.com/facebook/rocksdb/commit/1953b63cddf1a6779e7a7cfd7d28920b59ef6b6a

thatsafunnyname

comment created time in 21 days

push eventthatsafunnyname/rocksdb

Peter (Stig) Edwards

commit sha 58f6032881bde7ddc9ed7863297db1838431d0cb

Avoid ZFS check in IsSyncFileRangeSupported if ROCKSDB_DO_NOT_CHECK_ZFS_SYNC_FILE_RANGE is defined.

view details

push time in a month

Pull request review commentfacebook/rocksdb

Kill whitebox crash test if it is 15 minutes over the limit

 def blackbox_crash_main(args, unknown_args):           + "total-duration=" + str(cmd_params['duration']) + "\n")      while time.time() < exit_time:-        run_had_errors = False-        killtime = time.time() + cmd_params['interval']-         cmd = gen_cmd(dict(             list(cmd_params.items())             + list({'db': dbname}.items())), unknown_args) -        child = subprocess.Popen(cmd, stderr=subprocess.PIPE)-        print("Running db_stress with pid=%d: %s\n\n"-              % (child.pid, ' '.join(cmd)))--        stop_early = False-        while time.time() < killtime:-            if child.poll() is not None:-                print("WARNING: db_stress ended before kill: exitcode=%d\n"-                      % child.returncode)-                stop_early = True-                break-            time.sleep(1)--        if not stop_early:-            if child.poll() is not None:-                print("WARNING: db_stress ended before kill: exitcode=%d\n"-                      % child.returncode)-            else:-                child.kill()-                print("KILLED %d\n" % child.pid)-                time.sleep(1)  # time to stabilize after a kill--        while True:-            line = child.stderr.readline().strip().decode('utf-8')-            if line == '':-                break-            elif not line.startswith('WARNING'):+        hit_timeout, retcode, outs, errs = execute_cmd(cmd, cmd_params['interval'])++        if not hit_timeout:+            print('Exit Before Killing') +            print('stdout:')+            print(outs)+            print('stderr:')+            print(errs)+            sys.exit(2)++        for line in errs.split('\n'):+            if line != '' and  not line.startswith('WARNING'):                 run_had_errors = True

I noticed https://lgtm.com/projects/g/facebook/rocksdb/snapshot/b215f1a83226f111ff52305987af93564272b7d3/files/tools/db_crashtest.py?sort=name&dir=ASC&mode=heatmap#xf254f528ad18f108:1 is correctly reporting that run_had_errors is now unused. Xref: https://github.com/facebook/rocksdb/pull/8599

siying

comment created time in 3 months

PullRequestReviewEvent

PR opened facebook/rocksdb

Remove unused variable - run_had_errors

Unused since https://github.com/facebook/rocksdb/commit/ab718b415fc9b2a66a2ed642c18803f764839d7b . Noticed on https://lgtm.com/projects/g/facebook/rocksdb/snapshot/b215f1a83226f111ff52305987af93564272b7d3/files/tools/db_crashtest.py?sort=name&dir=ASC&mode=heatmap#xf254f528ad18f108:1

+0 -1

0 comment

1 changed file

pr created time in 3 months

push eventthatsafunnyname/rocksdb

Peter (Stig) Edwards

commit sha 22b4cdfd45f34c9c3b935cd99a68aa17e0cb5857

Remove unused variable - run_had_errors Unused since https://github.com/facebook/rocksdb/commit/ab718b415fc9b2a66a2ed642c18803f764839d7b . Noticed on https://lgtm.com/projects/g/facebook/rocksdb/snapshot/b215f1a83226f111ff52305987af93564272b7d3/files/tools/db_crashtest.py?sort=name&dir=ASC&mode=heatmap#xf254f528ad18f108:1

view details

push time in 3 months