Ah. I think I know what's going on here.
Can you share the output of $ docker images | grep kaskara?

My hunch is that that Kaskara is missing an install hook for building its Docker image. To manually rectify the problem, you should be able to download the image from DockerHub via: $ docker pull christimperley/kaskara.

Let me know if that solves your problem!

I didn't have kaskara in my original env - unfortunately, downloading that docker image didn't work either. I still got the kaskara tool exception.

BTW, I installed the docker image in my virtualenv...

any other ideas?

I don't suppose that the exception came with a stack trace?

Ah. It looks like Kaskara uses the squareslab/kaskara image (not christimperley/kaskara).

PLUGIN = Plugin(name='kaskara',
                image='squareslab/kaskara',
                environment={'PATH': '/opt/kaskara/scripts:${PATH}'})

thanks for responding so quickly and sorry I didn't back to this - got involved with a more pressing issue. Let me try installing the squareslab/kaskara and get back to you!!
---- i'm also logging the stdout/stderr will send that with next update if it does not pass.

Good news: no more kaskara tool issue, but still failing.

Here's the traceback after the Localization:
27647 Traceback (most recent call last):
27648 File "/home/bss-lab-1/Darjeeling/djling_venv/bin/darjeeling", line 10, in
27649 sys.exit(main())
27650 File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/darjeeling/cli/__init __.py", line 392, in main
27651 app.run()
27652 File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/cement/core/foundatio n.py", line 916, in run
27653 return_val = self.controller._dispatch()
27654 File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/cement/ext/ext_argpar se.py", line 808, in _dispatch
27655 return func()
27656 File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/darjeeling/cli/__init __.py", line 308, in repair
27657 files)
27658 File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/kaskara/analysis.py", line 50, in build
27659 ignore_exit_code=ignore_exit_code)
27660 File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/kaskara/loops.py", li ne 38, in find_loops
27661 raise BondException(msg)
27662 kaskara.exceptions.BondException: loop finder exited with non-zero code: 139

That looks like an issue with one of Kaskara's static analysers -- I'll look into that and get it fixed today.

In the meantime, as a Hello World example, can you try to run Darjeeling on the zune benchmark (tse2012:zune) from TSE 2012?

(darjeeling) $ git clone git@github.com:BugZooOrg/genprog-tse-2012-bugs tse2012
(darjeeling) $ cd tse2012
(darjeeling) $ bugzoo source add tse2012 .
(darjeeling) $ darjeeling repair your-repair-file.yml

To get that up and running, you'll need to install the latest version of BugZoo (2.1.26), which fixes a coverage instrumentation issue that affects older C code.

I ran this [btw, i had to bugzoo bug build tse2012:zune between your last two steps].
Here's the output from :

connecting to BugZoo server
connected to BugZoo server
computing coverage information...
Traceback (most recent call last):
File "/home/bss-lab-1/Darjeeling/djling_venv/bin/darjeeling", line 10, in
sys.exit(main())
File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/darjeeling/cli/ init.py", line 392, in main
app.run()
File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/cement/core/foundation.py", line 916, in run
return_val = self.controller._dispatch()
File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/cement/ext/ext_argparse.py", line 808, in _dispatch
return func()
File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/darjeeling/cli/ init.py", line 288, in repair
coverage = client_bugzoo.bugs.coverage(snapshot)
File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/bugzoo/client/bug.py", line 103, in coverage
self.__api.handle_erroneous_response(r)
File "/home/bss-lab-1/Darjeeling/djling_venv/lib/python3.6/site-packages/bugzoo/client/api.py", line 95, in handle_erroneous_response
raise err
bugzoo.exceptions.FailedToComputeCoverage: failed to compute coverage: unknown reason.

more information:

(djling_venv) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.zune$ darjeeling repair sample.yml |& tee darjeeling.repair.log ^C
(djling_venv) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.zune$ cat sample.yml 
version: '1.0'
snapshot: 'tse2012:zune'
language: c
seed: 0
threads: 16
localization:
  type: spectrum
  metric: tarantula
  exclude-files:
    - foo.c
algorithm:
  type: exhaustive
transformations:
  schemas:
    - type: delete-statement
    - type: replace-statement
    - type: prepend-statement
optimizations:
  ignore-equivalent-prepends: yes
  ignore-dead-code: yes
  ignore-string-equivalent-snippets: yes
resource-limits:
  candidates: 5000
  time-minutes: 3600

Can you share the output of $ pip list?
That looks like the bug that was fixed in BugZoo 2.1.26.

Yup - looks like I am on version 2.1.22 --- I did run pipenv install bugzoo before I launched :-\

(djling_venv) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.zune$ pip list | grep -i bugzoo
bugzoo           2.1.22

Fixed - wrong command, my bad.

(djling_venv) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.zune$ pip list | grep -i bugzoo
bugzoo           2.1.26

We have successful execution of Darjeeling on tse2012:zune !

...
evaluated candidate: Candidate<#7d545420>
failed to find a patch
waiting for pending evaluations to complete.
finished waiting for pending evaluations to complete.
found 0 plausible patches
time taken: 0.55 minutes
# test evaluations: 308
# candidate evaluations: 25

Hey Chris -
I added logging.basicConfig(filename=__name__+".log",level=logging.DEBUG) to my kaskara/loops.py to log the DEBUG information to a file.
I hope the following can help:

27730 DEBUG:bugzoo.client.api:transformed path [containers/d4d6b8b9-458e-45e6-bc3b-0cf40c0fd57d/exec] into url: http://127.0.0.1:6060/containers/d4d6b8      b9-458e-45e6-bc3b-0cf40c0fd57d/exec
27731 DEBUG:bugzoo.client.api:POST: http://127.0.0.1:6060/containers/d4d6b8b9-458e-45e6-bc3b-0cf40c0fd57d/exec
27732 DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 127.0.0.1:6060
27733 DEBUG:urllib3.connectionpool:http://127.0.0.1:6060 "POST /containers/d4d6b8b9-458e-45e6-bc3b-0cf40c0fd57d/exec HTTP/1.1" 200 30667
27734 DEBUG:kaskara.loops:executed loop finder [139]:
27735   Error while trying to load a compilation database:
27736   Could not auto-detect compilation database for file "Modules/_cryptmodule.c"
27737   No compilation database found in /experiment/src/Modules or any parent directory
27738   json-compilation-database: Error while opening JSON database: No such file or directory
27739   Running without flags.
27740   /experiment/src/Modules/_cryptmodule.c:4:10: fatal error: 'Python.h' file not found
27741   #include "Python.h"
27742            ^~~~~~~~~~
27743   1 error generated.
27744   Error while processing /experiment/src/Modules/_cryptmodule.c.
27745   /experiment/src/Objects/fileobject.c:4:10: fatal error: 'Python.h' file not found
27746   #include "Python.h"
27747            ^~~~~~~~~~
27748   1 error generated.
27749   Error while processing /experiment/src/Objects/fileobject.c.
.
.
.
28369   /experiment/src/Modules/expat/xmlparse.c:1529:12: warning: implicit conversion from enumeration type 'enum XML_Error' to different enumeration       type 'enum XML_Status' [-Wenum-conversion]
28370       return result;
28371       ~~~~~~ ^~~~~~
28372   /opt/kaskara/scripts/kaskara-loop-finder: line 5:    28 Segmentation fault      (core dumped) /opt/kaskara/bin/kaskara-loop-finder "$@"
28373 DEBUG:bugzoo.client.api:transformed path [containers/d4d6b8b9-458e-45e6-bc3b-0cf40c0fd57d] into url: http://127.0.0.1:6060/containers/d4d6b8b9-45      8e-45e6-bc3b-0cf40c0fd57d
28374 DEBUG:bugzoo.client.api:DELETE: http://127.0.0.1:6060/containers/d4d6b8b9-458e-45e6-bc3b-0cf40c0fd57d
28375 DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 127.0.0.1:6060
28376 DEBUG:urllib3.connectionpool:http://127.0.0.1:6060 "DELETE /containers/d4d6b8b9-458e-45e6-bc3b-0cf40c0fd57d HTTP/1.1" 204 0

Update: Kaskara, the static analysis library used by Darjeeling, fails on this particular bug (manybugs:python:69223-69224) due to a missing compilation_commands.json database (required by Clang's LibTooling). The compilation database is normally generated automatically by CMake projects, but can also be obtained using Bear for other projects. The permanent fix for this issue is for me to update Kaskara to mount portable Bear binaries into the container for the program under analysis and to rebuild the program whilst listening with Bear. In the interest of expediency, I'll tweak the ManyBugs Docker images to use Bear and therefore include a compilation_commands.json database.

I've pushed some changes to ManyBugs such that the PHP and Python scenarios should now have a compilation database: https://github.com/squaresLab/ManyBugs/pull/16

To quickly test whether Kaskara completes the static analysis of the bug:

import kaskara
import bugzoo.server

with bugzoo.server.ephemeral() as client_bugzoo:
    snapshot = client_bugzoo.bugs['manybugs:python:69223-69224']
    files = ['/experiment/src/Modules/_cryptmodule.c']
    kaskara.Analysis.build(client_bugzoo, snapshot, files)

If no errors occur, the static analysis was built.

Hey Chris - it looks like the manybugs dockerfile installation is a bit incomplete for kaskara static analysis, since it's missing the python typing module. I'm working through this right now - will post when i get the baseline ready.

That's interesting. Sounds good. Do you mind sharing the error log for the Python typing import failure?

Sure sure - it was just a python module resolution error [default python3 is 3.4.3]. After I resolved that, it looks like bugzoo was also required to be installed on the docker image, so that actually requires python 3.5 to be installed. now i'm questioning my sanity - i'm going back right now and duplicating these errors, since I've been messing around with the dockerfile. will post when I'm done.
BTW, i'm still on the add-bear branch of manybugs.

docker@a0a6ade7c794:/experiment$ PYTHONPATH=/usr/lib/python3.4:/opt/kaskara/python python3 timperley.py 
Traceback (most recent call last):
  File "timperley.py", line 1, in <module>
    import kaskara
  File "/opt/kaskara/python/kaskara/__init__.py", line 5, in <module>
    from .analysis import Analysis
  File "/opt/kaskara/python/kaskara/analysis.py", line 3, in <module>
    from typing import List, Optional, Dict, Any
ImportError: No module named 'typing'
docker@a0a6ade7c794:/experiment$

where timperley.py is the static analysis quick test from above:

import kaskara
import bugzoo.server

with bugzoo.server.ephemeral() as client_bugzoo:
    snapshot = client_bugzoo.bugs['manybugs:python:69223-69224']
    files = ['/experiment/src/Modules/_cryptmodule.c']
    kaskara.Analysis.build(client_bugzoo, snapshot, files)

I think what's happening here is that you're running the sanity checking script inside a Docker container rather than on the host machine (in a virtualenv where Kaskara and BugZoo are installed).

You're right, that's exactly what I'm doing!! ugh. with some distance from this, wow, what a bonehead move on my part.

...and static analysis in virtual env works

Not at all. I wasn't clear enough with my example, and Kaskara/BugZoo are quite unconventional in that they operate with Docker from outside of the container.

Regardless, I'm glad to hear that it's working!

Just FYI: I'm still getting that non-zero code 139, despite the passing kaskara static run. I've walked back through your debugging suggestions to figure out what is going on.
tool versions:
Darjeeling: remotes/origin/master [last commit: updated bugzoo version]
Manybugs: remotes/origin/add-bear [last commit: update bear command for PHP]

I logged into the docker and the processing looks fine for kaskara --- so i've dumped the debug log again to see what's changed, but there still seems to be a segfault:

28261 DEBUG:urllib3.connectionpool:http://127.0.0.1:6060 "POST /bugs/manybugs:python:69368-69372/provision HTTP/1.1" 200 126
28262 INFO:bugzoo.client.container:provisioned container (id: 60a534d5-11e1-4c99-8fb2-81a081104b90) for bug: manybugs:python:69368-69372
28263 DEBUG:kaskara.loops:executing loop finder [/experiment/src]: kaskara-loop-finder Objects/obmalloc.c Objects/codeobject.c Python/marshal.c Modules/binascii.c Modules/_randommodule.c Objects/dictobject.c Modules/_weakref.c Parser/grammar1.c Modules/atexitmodule.c Modules/resource.c Modules/_gdbmmodule.c Python/codecs.c Objects/boolobject.c Python/symtable.c Python/pystrtod.c Python/fileutils.c Objects/abstract.c Modules/posixmodule.c Modules/_localemodule.c Objects/frameobject.c Modules/_codecsmodule.c Modules/mathmodule.c Python/mystrtoul.c Modules/_sqlite/connection.c Modules/cjkcodecs/_codecs_kr.c Objects/structseq.c Objects/object.c Modules/_multiprocessing/multiprocessing.c Objects/stringlib/count.h Modules/nismodule.c Modules/_csv.c Objects/exceptions.c Modules/selectmodule.c Parser/firstsets.c Modules/arraymodule.c Objects/memoryobject.c Python/py      thonrun.c Python/sysmodule.c Parser/pgenmain.c Modules/_io/_iomodule.c Objects/bytesobject.c Objects/tupleobject.c Modules/_elementtree.c Python/pytime.c Modules/_collectionsmodule.c Modules/faulthandler.c Modules/_pickle.c Modules/cjkcodecs/multibytecodec.c Objects/classobject.c Python/dtoa.c Objects/weakrefobject.c Modul      es/_bz2module.c Python/mysnprintf.c Modules/_json.c Modules/_sqlite/cache.c Modules/_io/textio.c Modules/errnomodule.c Python/future.c Objects/stringlib/split.h Modules/_hashopenssl.c Python/getplatform.c Objects/fileobject.c Modules/unicodedata.c Modules/_cursesmodule.c Objects/stringlib/fastsearch.h Modules/cjkcodecs/_codecs_iso2022.c Objects/setobject.c Modules/gcmodule.c Modules/operator.c Modules/signalmodule.c Modules/_io/fileio.c Python/import.c Modules/_sqlite/row.c Modules/_sqlite/module.c Modules/cmathmodule.c Modules/cjkcodecs/_codecs_cn.c Modules/cjkcodecs/_codecs_tw.c Parser/acceler.c Modules/_functoolsmodule.c Python/thread.c       Modules/readline.c Python/getargs.c Parser/printgrammar.c Modules/_curses_panel.c Modules/grpmodule.c Object      s/unicodectype.c Modules/_sqlite/statement.c Objects/enumobject.c Include/pyatomic.h Python/thread_pthread.h       Python/getcompiler.c Objects/floatobject.c Python/asdl.c Objects/stringlib/formatter.h Parser/parser.c Modu      les/termios.c Python/modsupport.c Python/peephole.c Objects/bytearrayobject.c Modules/getbuildinfo.c Objects      /listobject.c Objects/rangeobject.c Parser/node.c Modules/_heapqmodule.c Modules/_threadmodule.c Modules/pyt      hon.c Objects/cellobject.c Python/traceback.c Objects/stringlib/partition.h Objects/longobject.c Modules/_ct      ypes/_ctypes.c Modules/timemodule.c Modules/_posixsubprocess.c Objects/stringlib/eq.h Modules/_sqlite/cursor      .c Objects/stringlib/find.h Modules/_bisectmodule.c Modules/zipimport.c Modules/_io/bufferedio.c Modules/_io      /iobase.c Parser/parsetok.c Modules/_tkinter.c Parser/tokenizer.c Python/pyarena.c Objects/sliceobject.c Obj      ects/moduleobject.c Modules/_lsprof.c Parser/bitset.c Python/getopt.c Parser/metagrammar.c Modules/_sqlite/p      repare_protocol.c Modules/pyexpat.c Modules/parsermodule.c Objects/typeobject.c Python/bltinmodule.c Modules      /_testcapimodule.c Objects/descrobject.c Python/ceval.c Modules/cjkcodecs/_codecs_hk.c Modules/_struct.c Pyt      hon/ceval_gil.h Python/importdl.c Modules/spwdmodule.c Modules/itertoolsmodule.c Python/_warnings.c Modules/      _sre.c Python/getcopyright.c Python/pystate.c Modules/main.c Modules/_cryptmodule.c Modules/cjkcodecs/cjkcod      ecs.h Modules/expat/xmlparse.c Python/ast.c Modules/mmapmodule.c Modules/_io/stringio.c Python/Python-ast.c       Modules/_sqlite/microprotocols.c Python/getversion.c Modules/syslogmodule.c Python/structmember.c Python/err      ors.c Objects/iterobject.c Objects/unicodeobject.c Objects/stringlib/string_format.h Parser/pgen.c Modules/p      wdmodule.c Modules/xxlimited.c Objects/genobject.c Modules/cjkcodecs/_codecs_jp.c Modules/_dbmmodule.c Parse      r/grammar.c Objects/methodobject.c Modules/_datetimemodule.c Modules/_ctypes/_ctypes_test.c Modules/socketmo      dule.c Python/compile.c Python/dynload_shlib.c Objects/funcobject.c Modules/zlibmodule.c Python/pymath.c Mod      ules/getpath.c Objects/stringlib/localeutil.h Modules/audioop.c Objects/capsule.c Modules/fcntlmodule.c
28264 DEBUG:bugzoo.client.api:transformed path [containers/60a534d5-11e1-4c99-8fb2-81a081104b90/exec] into url: ht      tp://127.0.0.1:6060/containers/60a534d5-11e1-4c99-8fb2-81a081104b90/exec
28265 DEBUG:bugzoo.client.api:POST: http://127.0.0.1:6060/containers/60a534d5-11e1-4c99-8fb2-81a081104b90/exec
28266 DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 127.0.0.1:6060
28267 DEBUG:urllib3.connectionpool:http://127.0.0.1:6060 "POST /containers/60a534d5-11e1-4c99-8fb2-81a081104b90/ex      ec HTTP/1.1" 200 209
28268 DEBUG:kaskara.loops:executed loop finder [139]:
28269   /opt/kaskara/scripts/kaskara-loop-finder: line 5:    28 Segmentation fault      (core dumped) /opt/kaskara      /bin/kaskara-loop-finder "$@"
28270 DEBUG:bugzoo.client.api:transformed path [containers/60a534d5-11e1-4c99-8fb2-81a081104b90] into url: http://      127.0.0.1:6060/containers/60a534d5-11e1-4c99-8fb2-81a081104b90
28271 DEBUG:bugzoo.client.api:DELETE: http://127.0.0.1:6060/containers/60a534d5-11e1-4c99-8fb2-81a081104b90
28272 DEBUG:urllib3.connectionpool:Starting new HTTP connection (1): 127.0.0.1:6060
28273 DEBUG:urllib3.connectionpool:http://127.0.0.1:6060 "DELETE /containers/60a534d5-11e1-4c99-8fb2-81a081104b90       HTTP/1.1" 204 0

I duplicated the list of files into the kaskara static analysis template and I was able to locally reproduce the segfault! I will email you the python code.

Hey Chris-

So, I can duplicate the failure on a docker image with the following:

$ docker create --name kaskara squareslab/kaskara
$ docker run --volumes-from kaskara --rm -it squareslab/manybugs:python-69223-69224
~ /opt/kaskara/scripts/kaskara-loop-finder /experiment/src/Modules/binascii.c

Can you point me to the kaskara source so that I can build the source code and debug the failure that occurs with binascii.c input?

minor aside: I found your dockerfile at https://hub.docker.com/r/christimperley/kaskara/dockerfile/, but I couldn't find the squareslab/kaskara install information. I know from previous conversations that these two images are different, but I'm sure that they're somewhat similar...

thanks!
-p

Great. Thanks for that!
I'm looking into the issue now.

The source code for Kaskara is at https://github.com/ChrisTimperley/Kaskara.

Interestingly, no fatal errors appear to be encountered when the other Kaskara scripts are run inside the container. That suggests that the problem is localised to loop-finder.cpp.

The function call, db_loop.add(ctx, stmt), in bool VisitWhileStmt(clang::WhileStmt const *stmt) seg. faults for the following stmt:

WhileStmt 0x3896e00
|-<<<NULL>>>
|-BinaryOperator 0x3895918 'int' '>'
| |-ImplicitCastExpr 0x3895900 'int' <IntegralCast>
| | `-UnaryOperator 0x38958c0 'unsigned char' prefix '--'
| |   `-DeclRefExpr 0x3895898 'unsigned char' lvalue Var 0x38869d0 'in_repeat' 'unsigned char'
| `-IntegerLiteral 0x38958e0 'int' 0
`-DoStmt 0x3896de0
  |-CompoundStmt 0x3896d98
  | |-IfStmt 0x3896c90
  | | |-<<<NULL>>>
  | | |-<<<NULL>>>
  | | |-BinaryOperator 0x38959c0 'int' '<'
  | | | |-UnaryOperator 0x3895968 'Py_ssize_t':'long' prefix '--'
  | | | | `-DeclRefExpr 0x3895940 'Py_ssize_t':'long' lvalue Var 0x3886bd8 'out_len_left' 'Py_ssize_t':'long'
  | | | `-ImplicitCastExpr 0x38959a8 'long' <IntegralCast>
  | | |   `-IntegerLiteral 0x3895988 'int' 0
  | | |-CompoundStmt 0x3896c50
  | | | |-IfStmt 0x3895cb8
  | | | | |-<<<NULL>>>
  | | | | |-<<<NULL>>>
  | | | | |-BinaryOperator 0x3895c10 'int' '>'
  | | | | | |-ImplicitCastExpr 0x3895bf8 'Py_ssize_t':'long' <LValueToRValue>
  | | | | | | `-DeclRefExpr 0x38959e8 'Py_ssize_t':'long' lvalue Var 0x3886b68 'out_len' 'Py_ssize_t':'long'
  | | | | | `-BinaryOperator 0x3895bd0 'long' '/'
  | | | | |   |-ParenExpr 0x3895b78 'Py_ssize_t':'long'
  | | | | |   | `-CStyleCastExpr 0x3895b50 'Py_ssize_t':'long' <IntegralCast>
  | | | | |   |   `-ParenExpr 0x3895b30 'size_t':'unsigned long'
  | | | | |   |     `-BinaryOperator 0x3895ac8 'size_t':'unsigned long' '>>'
  | | | | |   |       |-ParenExpr 0x3895a88 'size_t':'unsigned long'
  | | | | |   |       | `-CStyleCastExpr 0x3895a60 'size_t':'unsigned long' <IntegralCast>
  | | | | |   |       |   `-UnaryOperator 0x3895a30 'int' prefix '-'
  | | | | |   |       |     `-IntegerLiteral 0x3895a10 'int' 1
  | | | | |   |       `-IntegerLiteral 0x3895aa8 'int' 1
  | | | | |   `-ImplicitCastExpr 0x3895bb8 'long' <IntegralCast>
  | | | | |     `-IntegerLiteral 0x3895b98 'int' 2
  | | | | |-ReturnStmt 0x3895ca0
  | | | | | `-CallExpr 0x3895c78 'PyObject *'
  | | | | |   `-ImplicitCastExpr 0x3895c60 'PyObject *(*)(void)' <FunctionToPointerDecay>
  | | | | |     `-DeclRefExpr 0x3895c38 'PyObject *(void)' Function 0x37f2d40 'PyErr_NoMemory' 'PyObject *(void)'
  | | | | `-<<<NULL>>>
  | | | |-IfStmt 0x38966a0
  | | | | |-<<<NULL>>>
  | | | | |-<<<NULL>>>
  | | | | |-BinaryOperator 0x3895e70 'int' '<'
  | | | | | |-CallExpr 0x3895e18 'int'
  | | | | | | |-ImplicitCastExpr 0x3895e00 'int (*)(PyObject **, Py_ssize_t)' <FunctionToPointerDecay>
  | | | | | | | `-DeclRefExpr 0x3895cf0 'int (PyObject **, Py_ssize_t)' Function 0x373abc8 '_PyBytes_Resize' 'int (PyObject **, Py_ssize_t)'
  | | | | | | |-UnaryOperator 0x3895d40 'PyObject **' prefix '&'
  | | | | | | | `-DeclRefExpr 0x3895d18 'PyObject *' lvalue Var 0x3886a70 'rv' 'PyObject *'
  | | | | | | `-BinaryOperator 0x3895dd8 'long' '*'
  | | | | | |   |-ImplicitCastExpr 0x3895dc0 'long' <IntegralCast>
  | | | | | |   | `-IntegerLiteral 0x3895d60 'int' 2
  | | | | | |   `-ImplicitCastExpr 0x3895da8 'Py_ssize_t':'long' <LValueToRValue>
  | | | | | |     `-DeclRefExpr 0x3895d80 'Py_ssize_t':'long' lvalue Var 0x3886b68 'out_len' 'Py_ssize_t':'long'
  | | | | | `-IntegerLiteral 0x3895e50 'int' 0
  | | | | |-CompoundStmt 0x3896670
  | | | | | |-DoStmt 0x38964e8
  | | | | | | |-CompoundStmt 0x38964a8
  | | | | | | | `-IfStmt 0x3896470
  | | | | | | |   |-<<<NULL>>>
  | | | | | | |   |-<<<NULL>>>
  | | | | | | |   |-BinaryOperator 0x3896010 'int' '!='
  | | | | | | |   | |-UnaryOperator 0x3895fb8 'Py_ssize_t':'long' prefix '--'
  | | | | | | |   | | `-MemberExpr 0x3895f80 'Py_ssize_t':'long' lvalue ->ob_refcnt 0x3701a80
  | | | | | | |   | |   `-ParenExpr 0x3895f60 'PyObject *'
  | | | | | | |   | |     `-CStyleCastExpr 0x3895f38 'PyObject *' <NoOp>
  | | | | | | |   | |       `-ImplicitCastExpr 0x3895f20 'PyObject *' <LValueToRValue>
  | | | | | | |   | |         `-ParenExpr 0x3895f00 'PyObject *' lvalue
  | | | | | | |   | |           `-DeclRefExpr 0x3895e98 'PyObject *' lvalue Var 0x3886a70 'rv' 'PyObject *'
  | | | | | | |   | `-ImplicitCastExpr 0x3895ff8 'long' <IntegralCast>
  | | | | | | |   |   `-IntegerLiteral 0x3895fd8 'int' 0
  | | | | | | |   |-NullStmt 0x3896038
  | | | | | | |   `-ParenExpr 0x3896450 'void'
  | | | | | | |     `-CallExpr 0x3896420 'void'
  | | | | | | |       |-ImplicitCastExpr 0x3896408 'void (*)(PyObject *)' <FunctionToPointerDecay>
  | | | | | | |       | `-ParenExpr 0x3896298 'void (PyObject *)':'void (PyObject *)'
  | | | | | | |       |   `-UnaryOperator 0x3896278 'void (PyObject *)':'void (PyObject *)' prefix '*'
  | | | | | | |       |     `-ImplicitCastExpr 0x3896260 'destructor':'void (*)(PyObject *)' <LValueToRValue>
  | | | | | | |       |       `-MemberExpr 0x3896228 'destructor':'void (*)(PyObject *)' lvalue ->tp_dealloc 0x3711ba0
  | | | | | | |       |         `-ImplicitCastExpr 0x3896210 'struct _typeobject *' <LValueToRValue>
  | | | | | | |       |           `-ParenExpr 0x38961f0 'struct _typeobject *' lvalue
  | | | | | | |       |             `-MemberExpr 0x38961b8 'struct _typeobject *' lvalue ->ob_type 0x3701c30
  | | | | | | |       |               `-ParenExpr 0x3896198 'PyObject *'
  | | | | | | |       |                 `-CStyleCastExpr 0x3896170 'PyObject *' <NoOp>
  | | | | | | |       |                   `-ParenExpr 0x3896150 'PyObject *'
  | | | | | | |       |                     `-CStyleCastExpr 0x38960e8 'PyObject *' <NoOp>
  | | | | | | |       |                       `-ImplicitCastExpr 0x38960d0 'PyObject *' <LValueToRValue>
  | | | | | | |       |                         `-ParenExpr 0x38960b0 'PyObject *' lvalue
  | | | | | | |       |                           `-DeclRefExpr 0x3896048 'PyObject *' lvalue Var 0x3886a70 'rv' 'PyObject *'
  | | | | | | |       `-CStyleCastExpr 0x38963e0 'PyObject *' <NoOp>
  | | | | | | |         `-ParenExpr 0x38963c0 'PyObject *'
  | | | | | | |           `-CStyleCastExpr 0x3896358 'PyObject *' <NoOp>
  | | | | | | |             `-ImplicitCastExpr 0x3896340 'PyObject *' <LValueToRValue>
  | | | | | | |               `-ParenExpr 0x3896320 'PyObject *' lvalue
  | | | | | | |                 `-DeclRefExpr 0x38962b8 'PyObject *' lvalue Var 0x3886a70 'rv' 'PyObject *'
  | | | | | | `-IntegerLiteral 0x38964c8 'int' 0
  | | | | | |-CallExpr 0x3896590 'void'
  | | | | | | |-ImplicitCastExpr 0x3896578 'void (*)(Py_buffer *)' <FunctionToPointerDecay>
  | | | | | | | `-DeclRefExpr 0x3896508 'void (Py_buffer *)' Function 0x382bdf0 'PyBuffer_Release' 'void (Py_buffer *)'
  | | | | | | `-UnaryOperator 0x3896558 'Py_buffer *' prefix '&'
  | | | | | |   `-DeclRefExpr 0x3896530 'Py_buffer':'struct bufferinfo' lvalue Var 0x38867a8 'pin' 'Py_buffer':'struct bufferinfo'
  | | | | | `-ReturnStmt 0x3896658
  | | | | |   `-ImplicitCastExpr 0x3896640 'PyObject *' <NullToPointer>
  | | | | |     `-ParenExpr 0x3896620 'void *'
  | | | | |       `-CStyleCastExpr 0x38965f8 'void *' <NullToPointer>
  | | | | |         `-IntegerLiteral 0x38965c0 'int' 0
  | | | | `-<<<NULL>>>
  | | | |-BinaryOperator 0x3896a48 'unsigned char *' '='
  | | | | |-DeclRefExpr 0x38966d8 'unsigned char *' lvalue Var 0x38868b0 'out_data' 'unsigned char *'
  | | | | `-BinaryOperator 0x3896a20 'unsigned char *' '+'
  | | | |   |-CStyleCastExpr 0x38969b8 'unsigned char *' <BitCast>
  | | | |   | `-ParenExpr 0x3896998 'char *'
  | | | |   |   `-BinaryOperator 0x3896970 'char *' ','
  | | | |   |     |-ParenExpr 0x38967a8 'void'
  | | | |   |     | `-CStyleCastExpr 0x3896780 'void' <ToVoid>
  | | | |   |     |   `-ParenExpr 0x3896760 'int'
  | | | |   |     |     `-IntegerLiteral 0x3896700 'int' 0
  | | | |   |     `-ImplicitCastExpr 0x3896958 'char *' <ArrayToPointerDecay>
  | | | |   |       `-ParenExpr 0x38968e8 'char [1]' lvalue
  | | | |   |         `-MemberExpr 0x38968b0 'char [1]' lvalue ->ob_sval 0x3739530
  | | | |   |           `-ParenExpr 0x3896890 'PyBytesObject *'
  | | | |   |             `-CStyleCastExpr 0x3896868 'PyBytesObject *' <BitCast>
  | | | |   |               `-ImplicitCastExpr 0x3896850 'PyObject *' <LValueToRValue>
  | | | |   |                 `-ParenExpr 0x3896830 'PyObject *' lvalue
  | | | |   |                   `-DeclRefExpr 0x38967c8 'PyObject *' lvalue Var 0x3886a70 'rv' 'PyObject *'
  | | | |   `-ImplicitCastExpr 0x3896a08 'Py_ssize_t':'long' <LValueToRValue>
  | | | |     `-DeclRefExpr 0x38969e0 'Py_ssize_t':'long' lvalue Var 0x3886b68 'out_len' 'Py_ssize_t':'long'
  | | | |-BinaryOperator 0x3896b38 'Py_ssize_t':'long' '='
  | | | | |-DeclRefExpr 0x3896a70 'Py_ssize_t':'long' lvalue Var 0x3886bd8 'out_len_left' 'Py_ssize_t':'long'
  | | | | `-BinaryOperator 0x3896b10 'long' '-'
  | | | |   |-ImplicitCastExpr 0x3896ae0 'Py_ssize_t':'long' <LValueToRValue>
  | | | |   | `-DeclRefExpr 0x3896a98 'Py_ssize_t':'long' lvalue Var 0x3886b68 'out_len' 'Py_ssize_t':'long'
  | | | |   `-ImplicitCastExpr 0x3896af8 'long' <IntegralCast>
  | | | |     `-IntegerLiteral 0x3896ac0 'int' 1
  | | | `-BinaryOperator 0x3896c28 'Py_ssize_t':'long' '='
  | | |   |-DeclRefExpr 0x3896b60 'Py_ssize_t':'long' lvalue Var 0x3886b68 'out_len' 'Py_ssize_t':'long'
  | | |   `-BinaryOperator 0x3896c00 'long' '*'
  | | |     |-ImplicitCastExpr 0x3896bd0 'Py_ssize_t':'long' <LValueToRValue>
  | | |     | `-DeclRefExpr 0x3896b88 'Py_ssize_t':'long' lvalue Var 0x3886b68 'out_len' 'Py_ssize_t':'long'
  | | |     `-ImplicitCastExpr 0x3896be8 'long' <IntegralCast>
  | | |       `-IntegerLiteral 0x3896bb0 'int' 2
  | | `-<<<NULL>>>
  | `-BinaryOperator 0x3896d70 'unsigned char' '='
  |   |-UnaryOperator 0x3896d10 'unsigned char' lvalue prefix '*'
  |   | `-UnaryOperator 0x3896cf0 'unsigned char *' postfix '++'
  |   |   `-DeclRefExpr 0x3896cc8 'unsigned char *' lvalue Var 0x38868b0 'out_data' 'unsigned char *'
  |   `-ImplicitCastExpr 0x3896d58 'unsigned char' <LValueToRValue>
  |     `-DeclRefExpr 0x3896d30 'unsigned char' lvalue Var 0x3886958 'in_byte' 'unsigned char'
  `-IntegerLiteral 0x3896dc0 'int' 0

Drilling down further, bool VisitWhileStmt(clang::WhileStmt const *stmt) dies on the following call for the above stmt:
std::string body = build_loc_str(stmt->getBody()->getSourceRange(), ctx);

The previous call in the VisitWhileStmt function, std::string location = build_loc_str(stmt->getSourceRange(), ctx), reveals the troublesome statement to be located at /experiment/src/Modules/binascii.c@841:16::806:14.

The offending while loop (/experiment/src/Modules/binascii.c@841:16::806:14):

while ( --in_repeat > 0 )
  OUTBYTE(in_byte);

Failure occurs in util.cpp:build_loc_str at the following line:

std::string filename = SM.getFileEntryForID(file_id)->tryGetRealPathName();

It looks like the file_id is likely invalid. This might have something to do with the loop body being a macro expansion.

SM.getFileEntryForID(file_id) returns nullptr, but strangely file_id.isValid() evaluates to true. Switching to a newer version of Clang would remove the need for most of the operations in util.cpp:build_loc_str and may avoid this problem.

As suspected, the SourceLocation corresponds to a macro ID, which contains both a spelling location and an instantiation location -- we only want the latter.
(https://stackoverflow.com/questions/24062989/clang-fails-replacing-a-statement-if-it-contains-a-macro)

Is that a big impact to the other parts of the toolchain?

It shouldn't be much of a problem. The issue should be fixed: https://github.com/ChrisTimperley/Kaskara/pull/37
I'll push an updated image to DockerHub.

Pushed to squareslab/kaskara.

cool - it looks like from the original list of failing files, 5 / 34 of the failures were addressed, but this patch introduced a lot more segfaults [last version 34 / 185 segfaults => this update 137 / 185 segfaults]

I have preserved a file list for both - i'm not sure how you want to proceed, but here's a small subset of each:
failing in both kaskara versions:
/experiment/src/Objects/dictobject.c
/experiment/src/Python/symtable.c

failing in new kaskara version:
/experiment/src/Python/compile.c
/experiment/src/Objects/funcobject.c
/experiment/src/Modules/zlibmodule.c
/experiment/src/Python/pymath.c

Since you sent me the source last week, I'm starting debug too. If there's a particular debug item you think I should focus on, let me know!
-p

Do you know which Kaskara programs (e.g., kaskara-loop-finder) those files are failing on?

I walked through each input file using that same infrastructure you sent before, but files[] are all input files for that python bug - i think it does use kaskara-loop-finder:

mport sys,os
import kaskara
import bugzoo.server


with bugzoo.server.ephemeral() as client_bugzoo:
	snapshot = client_bugzoo.bugs['manybugs:python:69223-69224']
	files = [ '/experiment/src/Objects/obmalloc.c',
	'/experiment/src/Objects/codeobject.c',
	'/experiment/src/Python/marshal.c',
	'/experiment/src/Modules/binascii.c', # this looks like it's failing with first 3
	'/experiment/src/Modules/_randommodule.c',
	'/experiment/src/Objects/dictobject.c',
	'/experiment/src/Modules/_weakref.c',
	'/experiment/src/Parser/grammar1.c',
	'/experiment/src/Modules/atexitmodule.c',
	'/experiment/src/Modules/resource.c',
...

	'/experiment/src/Modules/audioop.c',
	'/experiment/src/Objects/capsule.c',
	'/experiment/src/Modules/fcntlmodule.c'
	]


	count = 0
	fh = open("kaskara.failing_input.log","w")
	while count<len(files):
		myfiles = files[count:count+1]
		try:
			kaskara.Analysis.build(client_bugzoo, snapshot, myfiles)
			print(str(count)+" works") 

		except:
			print(str(count)+" exception : "+str(files[count])) 
			fh.write(files[count]+"\n")
			fh.flush()
		count+=1
	fh.close()

(Darjeeling-CMU-25-03-2019) bss-lab

That's strange. I'm not seeing any seg faults or crashes on my machine. Just to confirm: have you downloaded / rebuilt the latest image for squareslab/kaskara?

I thought I did - let me rebuild everything and remove old squareslab/kaskara images again. will post what I find.

So, it looks like my darjeeling and python kaskara infrastructure / virtualenv is not in a good state. I'm just using the docker run command until I figure that out:
docker pull squareslab/kaskara && docker create --name kaskara squareslab/kaskara && docker run --volumes-from kaskara --rm -it squareslab/manybugs:python-69223-69224

Did this file /experiment/src/Modules/posixmodule.c pass for you?

docker@d86628a21b5d:/experiment$ /opt/kaskara/scripts/kaskara-loop-finder /experiment/src/Modules/posixmodule.c
recording for-stmt
recorded for-stmt
recording for-stmt
recorded for-stmt
recording for-stmt
recorded for-stmt
recording for-stmt
recorded for-stmt
recording for-stmt
recorded for-stmt
recording for-stmt
recorded for-stmt
recording while-stmt
WhileStmt 0x2249bd8
|-<<<NULL>>>
|-BinaryOperator 0x2249a68 'int' '>='
| |-UnaryOperator 0x2249a10 'Py_ssize_t':'long' prefix '--'
| | `-DeclRefExpr 0x22499e8 'Py_ssize_t':'long' lvalue Var 0x2241110 'envc' 'Py_ssize_t':'long'
| `-ImplicitCastExpr 0x2249a50 'long' <IntegralCast>
|   `-IntegerLiteral 0x2249a30 'int' 0
`-CallExpr 0x2249b78 'void'
  |-ImplicitCastExpr 0x2249b60 'void (*)(void *)' <FunctionToPointerDecay>
  | `-DeclRefExpr 0x2249a90 'void (void *)' Function 0x1ed5f40 'free' 'void (void *)'
  `-ImplicitCastExpr 0x2249bc0 'void *' <BitCast>
    `-ImplicitCastExpr 0x2249ba8 'char *' <LValueToRValue>
      `-ArraySubscriptExpr 0x2249b38 'char *' lvalue
        |-ImplicitCastExpr 0x2249b08 'char **' <LValueToRValue>
        | `-DeclRefExpr 0x2249ab8 'char **' lvalue Var 0x2240fa8 'envlist' 'char **'
        `-ImplicitCastExpr 0x2249b20 'Py_ssize_t':'long' <LValueToRValue>
          `-DeclRefExpr 0x2249ae0 'Py_ssize_t':'long' lvalue Var 0x2241110 'envc' 'Py_ssize_t':'long'
fetching body
/opt/kaskara/scripts/kaskara-loop-finder: line 5:    57 Segmentation fault      (core dumped) /opt/kaskara/bin/kaskara-loop-finder "$@"
docker@d86628a21b5d:/experiment$

I'm going to build your kaskara-loop-finder image locally and run it on all the inputs. I think this will be easier for me in the long run.

I can confirm that I see the same error for that file. I'll look into it.

I think I've found the issue and a working fix. Once again, macros aren't being treated correctly: Kaskara is using the spelling location for each macro (i.e., macro definition) rather than the expansion location (i.e., macro call). I've created a PR that should fix the bug: https://github.com/ChrisTimperley/Kaskara/pull/38

Let me know if it works for you and I'll go ahead and merge.

I've also pushed a new version of the image to squareslab/kaskara.

Cool - Thanks Chris. I’m 15min away from my laptop/VNC session, will check ASAP.

Your changes to the latest squareslab/kaskara has enabled ALL input files to pass kaskara-loop-finder without a segmentation fault!
Nice job!!!

Awesome :slight_smile:

I am having serious difficulties getting the kaskara infrastructure to build, so please let me know when that kaskara 0.0.6 is online and ready to be used by Darjeeling!
FYI: This morning I tried to reference it in a local build of the darjeeling virtualenv where I updated kaskara to 0.0.6 and it didn't look like it was available.

Ah. v0.0.6 hadn't been tagged as a GitHub release, so Travis didn't automatically push it to PyPI. I've gone ahead and tagged v0.0.6, so I would expect to see it on PyPI in ~10 minutes.

okay, so locally kaskara looks great, but when I create a local darjeeling with the updated kaskara version [0.0.6], I'm getting the bugzoo coverage issue again, even though I'm on bugzoo version 2.1.26 and using the add-bear branch on manybugs:

(Darjeeling) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.python.2$ darjeeling repair sample.yml 
/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/darjeeling/cli/__init__.py:102: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  yml = yaml.load(f)
search will terminate when an acceptable patch has been discovered
using threads specified by configuration: 16 threads
using time limit specified by configuration: 3600 minutes
using candidate limit specified by configuration: 5000 candidates
using random number generator seed provided by configuration: 0
using language: c
using repair settings: Settings(use_scope_checking=True, use_syntax_scope_checking=True, ignore_dead_code=True, ignore_equivalent_appends=True, ignore_untyped_returns=True, ignore_string_equivalent_snippets=True, ignore_decls=True, only_insert_executed_code=True)
connecting to BugZoo server
connected to BugZoo server
computing coverage information...
Traceback (most recent call last):
  File "/home/bss-lab-1/Darjeeling/Darjeeling/bin/darjeeling", line 10, in <module>
    sys.exit(main())
  File "/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/darjeeling/cli/__init__.py", line 392, in main
    app.run()
  File "/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/cement/core/foundation.py", line 916, in run
    return_val = self.controller._dispatch()
  File "/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/cement/ext/ext_argparse.py", line 808, in _dispatch
    return func()
  File "/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/darjeeling/cli/__init__.py", line 288, in repair
    coverage = client_bugzoo.bugs.coverage(snapshot)
  File "/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/client/bug.py", line 128, in coverage
    self.__api.handle_erroneous_response(r)
  File "/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/client/api.py", line 96, in handle_erroneous_response
    raise err
bugzoo.exceptions.FailedToComputeCoverage: failed to compute coverage: unknown reason.
(Darjeeling) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.python.2$ pip list | egrep '(darjeeling|kaskara|bugzoo)'
bugzoo           2.1.26  
darjeeling       0.1.13  
kaskara          0.0.6   
(Darjeeling) bss-lab-1@bsslab1-Precision-Tower-5810:~/Darjeeling/tea_sampler.python.2$ bugzoo source list | egrep '(manybugs)'
/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/mgr/source.py:83: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  registry = yaml.load(f)
/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/mgr/source.py:191: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  yml = yaml.load(f)
| another-manybugs | Local  | -                                          | /home/bss-lab-1/BugZoo/manyBugs-repo-22-01-2019                    | -         |
| my_manybugs      | Local  | -                                          | /home/bss-lab-1/ManyBugs/myManyBugs                                | -         |
| manybugs         | Local  | -                                          | /home/bss-lab-1/ManyBugs/ManyBugs-CMU-20-03-2019                   | -         |
| remote_manybugs  | Remote | https://github.com/squaresLab/ManyBugs     | /home/bss-lab-1/.bugzoo/sources/github_com_squaresLab_ManyBugs     | ad83bd9a  |

Is there something conflicting within this configuration?

Unfortunately, I did NOT preserve a window with the last environment, but I diff'd the tool configurations between the current and the last physical darjeeling directory in which I invoked the virtualenv.
Here's a list of deltas:

current: bdist_wheel (0.33.1)
previous: bdist_wheel (0.32.3)

current: docker (3.7.2)
previous: docker (3.7.1)

current: werkzeug (0.15.2)
previous: werkzeug (0.15.1)

Just to check, can you run bugzoo bug coverage manybugs:python:69223-69224 and dump the output?

sure thing - it's currently building and running with the manybugs add-bear branch. will post its STDOUT after it's done.
BTW, I did actually do that command earlier, but it was kind of a one-off as I neither captured the STDOUT [I didn't see anything seriously amiss in the last screen?], nor was that rigorous in my approach [i can't remember if it was before or after I moved manybugs back to the source].

ss-lab-1@bsslab1-Precision-Tower-5810:~/NeutralMutations/mutational_robustness/online_estimation/fauxware$ tail -n 10 ~/Darjeeling/Darjeeling/python.coverage.log 
  Python/sysmodule.c: 44; 46..48; 50; 54; 56..58; 65; 203; 206..207; 209..211; 223; 225..226; 229..230; 258; 260..261; 430; 432..433; 435..438; 635; 638..640; 642; 644; 646; 648; 650; 652; 917; 919..920; 922; 925..927; 929; 934..935; 1097; 1099; 1101; 1103..1104; 1106; 1108..1109; 1111; 1115..1118; 1120; 1126; 1128..1129; 1157; 1159; 1165; 1167..1169; 1171; 1211; 1213; 1346; 1348; 1351..1352; 1358..1366; 1372..1373; 1376; 1379; 1406; 1410; 1412..1413; 1422; 1436..1440; 1444; 1464; 1469..1470; 1472; 1487..1488; 1499; 1501; 1503; 1505; 1507; 1510; 1512; 1514; 1516; 1518; 1521; 1523; 1525; 1527; 1529; 1532..1534; 1536; 1538; 1543; 1546; 1550..1551; 1561; 1564..1565; 1570..1571; 1574..1576; 1580..1582; 1584..1585; 1588..1590; 1592..1593; 1607; 1615; 1617; 1621; 1627..1631; 1633..1634; 1636..1641; 1645..1646; 1648..1649; 1654; 1657; 1659; 1661..1662; 1665; 1668; 1674..1675; 1677; 1692; 1694; 1699; 1702; 1710; 1713..1714; 1720; 1728..1729; 1732; 1735; 1737; 1786; 1794; 1802..1803; 1805; 1807; 1811; 1813..1814; 1816; 1818..1821; 1824; 1826..1827
  Python/thread.c: 73; 85..87
  Python/thread_pthread.h: 181; 193; 197; 201; 203; 211; 214; 225; 227; 230; 233; 246; 249; 251..252; 271; 274; 277; 280; 282..284; 286; 293; 297; 299..300; 304..305; 307..308; 310; 322; 326; 330..331; 337..338; 340..343; 345; 348; 351..354; 356..358; 361; 365; 367; 370; 375; 379; 381..382; 386..388; 541; 543; 594; 597..598; 602; 604..605; 614; 617..618; 620..621
  Python/traceback.c: 45; 47..53; 56; 58..59; 64; 66..68; 106; 109..110; 114..122; 124; 128; 130..133; 135..136/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/mgr/source.py:83: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  registry = yaml.load(f)
/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/mgr/source.py:191: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  yml = yaml.load(f)
/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/core/coverage.py:212: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
  d = yaml.load(f)

From the log, it looks like coverage is working.

It's a huge output - but it looked like it passed?

bss-lab-1@bsslab1-Precision-Tower-5810:~/NeutralMutations/mutational_robustness/online_estimation/fauxware$ egrep -i '(segmentation|error|warn)' ~/Darjeeling/Darjeeling/python.coverage.log  | egrep -v 'Python/errors\.c' | egrep -v 'Python/_warnings\.c' | egrep -i '(error|warn|segmentation)'
  Python/traceback.c: 45; 47..53; 56; 58..59; 64; 66..68; 106; 109..110; 114..122; 124; 128; 130..133; 135..136/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/mgr/source.py:83: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/mgr/source.py:191: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
/home/bss-lab-1/Darjeeling/Darjeeling/lib/python3.6/site-packages/bugzoo/core/coverage.py:212: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
bss-lab-1@bsslab1-Precision-Tower-5810:~/NeutralMutations/mutational_robustness/online_estimation/fauxware$

Yep, it looks like it passed.

BTW, I finally got back to Darjeeling and tracked down the source of my problems - I had a bugzood process still connected to the localhost:6060 port and even though Darjeeling was updated, the flask APIs seemed to be pointing to an out of date version. I had to manually kill the service associated with that port. Now it looks great! Thanks, Chris!

I'm glad to hear you got it working :thumbsup: