wangpeipei90 / cloud9 Goto Github PK

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

[deleted issue]

Cloud9 could use a lot of engineering love. It would be good to invite people 
to contribute features and patches, and have a "wish list" of features that 
would make Cloud9 more robust and usable.

What steps will reproduce the problem?
1. use proxy scripts as described in 
http://cloud9.epfl.ch/testing-programs/producing-llvm-binaries

What is the expected output? What do you see instead?

Archiving blah.a ...
... cloud9/src/testing_targets/build//ar.proxy r blah.a foo.o bar.o
ar: no operation specified


Details of the patch :
 Proxy scripts append parameters from original command at the
 end of the command line. However, binutils ar util requires
 the command option to be passed as the second parameter.
 This patch checks for the command parameter and if present
 inserts it as the second option. Limitation: this patch
 only considers plain commands, not commands with options (a 
 proper reg exp should be used).

[deleted issue]

Currently, it is hard for newcomers to try out Cloud9 without having available 
a Linux box, and investing some time to install all the required parts.

An Amazon EC2 AMI would allow people to get up and running a Cloud9 
installation in minutes, and start testing software.

Reported by Paul Thompson

Executor.cpp (executeThreadExit)

3217 thrIt->second.enabled = false;
3218
3219 if (!schedule(state, false))
3220 return;
3221
3222 state.terminateThread(thrIt);

If fork-on-schedule is true, schedule may create other states. In this case, 
the thread will only be terminated in one of the states and will remain 
disabled in the others. At least, I think this is what could happen. A similar 
situation occurs in executeProcessExit.

What steps will reproduce the problem?
1. ./build_install_cloud9.sh $HOME/cloud9

What is the expected output? What do you see instead?
Automatic compilation works in normal environments, demo producer-consumer 
program should work ok.
Not thoroughly tested for unconventional environments and configurations though.


What version / revision number of the product are you using? On what
operating system?
Used revision 68aed2f8b032
Compiled on Ubuntu 10.04 LTS x64

Please provide any additional information below.
Would be great if the script is included into the main source branch and 
extended/maintained for other platforms as well.

The code (current git) uses deprecated method name: 
http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/basic_socket_
acceptor/io_service.html

Attached patch fixes it on my system (Fedora 17).

The thread set in an ExecutionState is sorted by Thread pointer values, and the 
nextThread() function may return a different thread depending on the memory 
layout of the Cloud9 process.

kexpr-tool.cpp:67:20: error: no matching constructor for initialization of
        'klee::ExprDeserializer'
    ExprDeserializer expr_deserializer(is, *expr_builder);
                     ^                 ~~~~~~~~~~~~~~~~~
/home/kiba/cloud9/src/cloud9/include/klee/data/ExprDeserializer.h:59:3:
note:
        candidate constructor not viable: requires 3 arguments, but 2 were
        provided
    ExprDeserializer(std::istream &is, ExprBuilder &expr_builder,
    ^
/home/kiba/cloud9/src/cloud9/include/klee/data/ExprDeserializer.h:57:7:
note:
        candidate constructor (the implicit copy constructor) not viable:
requires
        1 argument, but 2 were provided
class ExprDeserializer {
        ^
1 error generated.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

[deleted issue]

What steps will reproduce the problem?
1. Run a Cloud9 test on prod-cons (the quickstart tutorial).
2. Use the attached coverage-tool to read the coverage.bin present in 
test-prod-cons.
   $ coverage-tool test-prod-cons/coverage.bin

There should be values for all six fields. However, covered source lines, 
covered assembly lines, and both coverage percentages are all 0. After some 
investigating, I discovered that Cloud9 writes the coverage.bin file *before* 
the actual Cloud9 testing begins. Because of this, I edited the StatsTracker 
class (StatsTracker.h and StatsTracker.cpp). My StatsTracker class is different 
in the following ways:

1. writeDetailedCoverageSnapshot has a second boolean parameter: 
actually_write. If actually_write is true, coverageInfo is updated and  
coverage.bin is created. If actually_write is false, coverageInfo is still 
updated but coverage.bin is not created.

2. In the destructor, writeDetailedCoverageSnapShot is called.

So essentially, this is how my edited code works:
1. On object creation (constructor), coverageInfo is updated but coverage.bin 
is *not* written.
2. On object deallocation (destructor), coverageInfo is updated and 
coverage.bin is written.

I am using the latest version of Cloud9 on Ubuntu 12.04 LTS.


coverage-tool is my own creation. Feel free to add it to the Cloud9 tools and 
modify it all you like. It's yours now. 

I've also attached my modified StatsTracker.cpp and StatsTracker.h.

Thanks,
Will O'Leary

[deleted issue]

[deleted issue]

What steps will reproduce the problem?
1. Try building cloud9 on Ubuntu 12.10 with gcc version 4.7.2
2. When the command gclient sync is issued, errors are encountered while 
compiling the file dwarf_reader.cc in binutils/gold directory.
3. When source code is modified to take care of the errors, gclient removes the 
files and starts building afresh, thus doing away with the possibility of 
manually removing the error.

What is the expected output? What do you see instead?
My expectation is that instead of creating the files again, gclient would use 
the already existing files.

What version / revision number of the product are you using? On what
operating system?
Mentioned above.

Please provide any additional information below.

[deleted issue]

The first step towards a new build system detached from LLVM.

A few tweaks to the documentation:
- Package libfreetype6-dev is needed for installation (to be added to the sudo 
apt-get install  ... line).
- on the quickstart page step 4 
$CLOUD9_ROOT/src/cloud9/Release+Asserts/c9-worker should actually be  
$CLOUD9_ROOT/src/cloud9/Release+Asserts/bin/c9-worker (note the 'bin/').

With those tweaks installation and test went well.

What steps will reproduce the problem?
1. Run the Cloud9 tests (make test)

What is the expected output? What do you see instead?

A lot of Cloud9-specific tests are expected. Instead, most of them originate 
from KLEE.


Please use labels and text to provide additional information.

Moving Cloud9 to Github will simplify issue tracking and the patch submission 
process.

[deleted issue]

libfreetype6-dev also seems needed for compilation, it would be great if it 
could be added to the list of dependencies. 

This is the error I got on a 12.04 Ubuntu:
Error: Command src/testing_targets/build/gyp_testing_targets returned non-zero 
exit status 1 in /var/lib/jenkins/workspace/esd
Package freetype2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `freetype2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'freetype2' found
Traceback (most recent call last):
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/gyp", line 18, in <module>
    sys.exit(gyp.main(sys.argv[1:]))
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/__init__.py", line 471, in main
    options.circular_check)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/__init__.py", line 111, in Load
    depth, generator_input_info, check, circular_check)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 2378, in Load
    depth, check)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 430, in LoadTargetBuildFile
    includes, depth, check)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 384, in LoadTargetBuildFile
    build_file_data, PHASE_EARLY, variables, build_file_path)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 1053, in ProcessVariablesAndConditionsInDict
    build_file)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 1068, in ProcessVariablesAndConditionsInList
    ProcessVariablesAndConditionsInDict(item, phase, variables, build_file)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 1027, in ProcessVariablesAndConditionsInDict
    ProcessConditionsInDict(the_dict, phase, variables, build_file)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 904, in ProcessConditionsInDict
    variables, build_file)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 1053, in ProcessVariablesAndConditionsInDict
    build_file)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 1072, in ProcessVariablesAndConditionsInList
    expanded = ExpandVariables(item, phase, variables, build_file)
  File "/var/lib/jenkins/workspace/esd/src/testing_targets/build/../../third_party/gyp/pylib/gyp/input.py", line 714, in ExpandVariables
    (contents, p.returncode))
Exception: Call to 'pkg-config freetype2 --libs' returned exit status 1. while 
loading dependencies of 

What steps will reproduce the problem?
1. Follow the step on http://cloud9.epfl.ch/setting-up.
2. Reach to the step Build STP. 
3. Try to make -j3.

What is the expected output? What do you see instead?
-> error on making, getting the following error code. 

/home/user/cld9/src/third_party/stp/src/sat/core_prop/../core_prop/../core/../mt
l/Map.h:32:101: error: ‘hash’ was not declared in this scope, and no 
declarations were found by argument-dependent lookup at the point of 
instantiation [-fpermissive]
/home/user/cld9/src/third_party/stp/src/sat/core_prop/../core_prop/../core/../mt
l/Map.h:41:24: note: ‘uint32_t Minisat::hash(int64_t)’ declared here, later 
in the translation unit
make[2]: *** 
[/home/user/cld9/src/third_party/stp/src/sat/core_prop/Solver_prop.or] Error 1
make[2]: Leaving directory 
`/home/user/cld9/src/third_party/stp/src/sat/core_prop'
make[1]: *** [core_prop/lib_release.a] Error 2
make[1]: *** Waiting for unfinished jobs....


What version / revision number of the product are you using? On what
operating system?
I am just following the http://cloud9.epfl.ch/setting-up.
I have tried on Fresh installation of Ubuntu 12.10 64 Version & Fedora 18 64 
Version.

I've also tried to install gcc*, llvm*, minisat*, release* to make sure. But 
even after that getting the same error on both the OSes.


Please provide any additional information below.

Defect imported from our old Redmine setup. Needs investigation.

This will ensure a consistent framework for producing LLVM binaries.

Reported by Cristian Zamfir.

Currently Cloud9 only allows a single binary to be loaded and models fork() to 
provide multi-processor support and test distributed systems. Ideally, exec 
should also be supported and allow Cloud9 to load different binaries. This 
would be a better way to provide support for testing distributed systems