From 6acc6570e2b37752db382d8b51d6e217fa9a20a4 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 21:01:07 -0400 Subject: [PATCH 01/21] check in three paragraphs --- grants/speculative/visualize_rust_lifetime.md | 111 ++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 grants/speculative/visualize_rust_lifetime.md diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md new file mode 100644 index 000000000..deafb1524 --- /dev/null +++ b/grants/speculative/visualize_rust_lifetime.md @@ -0,0 +1,111 @@ +# General Grant Proposal + +* **Project:** Avoiding Rust Deadlocks via Visualizing Lifetime + +## Project Overview :page_facing_up: + +### Overview + +Rust is a new programming language designed to provide both safety guarantees like high-level languages and performance guarantees like low-level languages. To achieve this design purpose, Rust leverages static compiler checks to rule out severe memory and thread safety issues during compilation. At runtime, Rust behaves like C/C++ and provides performance as good as C/C++. Due to its safety and performance, Rust is increasingly adopted to build safety-critical software, such as OSes and browsers. Rust is also used to implement many software systems in the Web3 technology stack (e.g., substrate, polkadot, ink!). + +Rust’s compiler checks are based on a suite of ownership and lifetime rules. The basic rule allows one value to only have one owner variable, and the value is dropped (freed) when its owner variable ends its lifetime. Rust extends the basic rule to allow ownership to be moved and borrowed, but still guarantees all accesses to a value are within its owner variable’s lifetime scope. Besides safety checks, lifetime is also used for automated resource management. For example, there is no explicit Unlock() in Rust. A locking function call returns a reference of the protected variable, and when the reference ends its lifetime, Rust automatically releases the acquired lock (by implicitly calling Unlock()) to avoid lock-without-unlock bugs in C/C++. + +However, Rust’s lifetime rules are unique and complex. It is challenging for Rust programmers to infer where a variable’s lifetime ends. Therefore, it is not uncommon for them to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers’ expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to double-lock deadlocks or deadlocks due to acquiring locks in conflicting orders. + +In our previous work, we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to misunderstanding where the implicit unlock is called, including 30 double locks and seven deadlocks caused by acquiring locks in conflicting orders. Those deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They are from famous Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox), and severely hurt the reliability of those systems before being fixed. + + +A brief description of the project. + * An indication of how you will integrate this project into Substrate / Polkadot / Kusama. + * An indication of why your team is interested in creating this project. + +### Project Details +We expect the teams to already have a solid idea about the project's expected final state. + +Therefore, we ask the teams to submit (where relevant): +* Mockups/designs of any UI components +* API specifications of the core functionality +* An overview of the technology stack to be used +* Documentation of core components, protocols, architecture etc. to be deployed +* PoC/MVP or other relevant prior work or research on the topic + +### Ecosystem Fit +Are there any other projects similar to yours? If so, how is your project different? + +## Team :busts_in_silhouette: + +### Team members +* Name of team leader +* Names of team members + +### Team Website +* https:// + +### Legal Structure +Please provide the name and registered address of the legal entity executing the project. When applying via the General Grants program, these details can also be shared privately via the Google Form used for your application. + +### Team's experience +Please describe the team's relevant experience. If the project involves development work, then we'd appreciated if you can single out a few interesting code commits made by team members on their past projects. For research-related grants, references to past publications and projects in a related domain are helpful. + +### Team Code Repos +* https://github.com/ +* https://github.com/ + +### Team LinkedIn Profiles +* https://www.linkedin.com/ +* https://www.linkedin.com/ + +## Development Roadmap :nut_and_bolt: + +This section should break out the development roadmap into a number of milestones. Since the milestones will appear in the grant contract, it helps to describe the functionality we should expect, plus how we can check that such functionality exists in the product. Whenever milestones are delivered, we refer to the contract to ensure that everything has been delivered as expected. + +Below we provide an **example roadmap**. In the descriptions it should be clear how the project is related to Substrate and/or Polkadot. We recommend that the scope of the work can fit within a 3 month period and that teams structure their roadmap as 1 month = 1 milestone. + +For each milestone: +* Please be sure to include a specification of the software. The level of detail must be enough so that we are able to verify that the software meets the specification. +* Please include total amount of funding requested per milestone. +* Please note that we require documentation (e.g. tutorials, API specifications, architecture details) in each milestone. This ensures that the code can be widely used by the community. +* Please provide a test suite, comprising unit and integration tests, along with a guide on how to run these. +* Please commit to providing a dockerfiles for the delivery of your project. +* Please indicate the milestone duration, as well as number of Full-Time Employees working on each milestone, and include the number of days along with their cost per day. + +### Overview +* **Total Estimated Duration:** Duration of the whole project +* **Full-time equivalent (FTE):** Workload of an employed person ([see](https://en.wikipedia.org/wiki/Full-time_equivalent)) +* **Total Costs:** Amount of Payment for the whole project. The total amount of funding needs to be below $100k. + +### Milestone 1 Example — Implement Substrate Modules +* **Estimated Duration:** 1 month +* **FTE:** 1 +* **Costs:** $5,000 + +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| 0a. | License | Apache 2.0 / MIT / Unlicense | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | +| 0c. | Testing Guide | The code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | +| 1. | Substrate module: X | We will create a Substrate module that will... (Please list the functionality that will be coded for the first milestone) | +| 2. | Substrate module: Y | We will create a Substrate module that will... | +| 3. | Substrate module: Z | We will create a Substrate module that will... | +| 4. | Substrate chain | Modules X, Y & Z of our custom chain will interact in such a way... (Please describe the deliverable here as detailed as possible) | +| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain | + +### Milestone 2 Example — Additional features +... + +### Community engagement + +As part of the Program, we require that you produce an article/tutorial and publish it (for example on [Medium](https://medium.com/)). It should explain your work done as part of the grant. + +Normally, we ask you to submit the write-up upon the completion of your grant, although for larger projects it might make sense to publish multiple articles after the completion of different milestones. + +## Future Plans +Please include the team's long-term plans and intentions. + +## Additional Information :heavy_plus_sign: +Any additional information that you think is relevant to this application that hasn't already been included. + +Possible additional information to include: +* What work has been done so far? +* Are there are any teams who have already contributed (financially) to the project? +* Have you applied for other grants so far? From 4461e3107ea12066a512b9cbda010fa521c4d7a5 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 21:12:29 -0400 Subject: [PATCH 02/21] finish description --- grants/speculative/visualize_rust_lifetime.md | 22 +++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index deafb1524..7a0901463 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -12,12 +12,26 @@ Rust’s compiler checks are based on a suite of ownership and lifetime rules. T However, Rust’s lifetime rules are unique and complex. It is challenging for Rust programmers to infer where a variable’s lifetime ends. Therefore, it is not uncommon for them to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers’ expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to double-lock deadlocks or deadlocks due to acquiring locks in conflicting orders. -In our previous work, we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to misunderstanding where the implicit unlock is called, including 30 double locks and seven deadlocks caused by acquiring locks in conflicting orders. Those deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They are from famous Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox), and severely hurt the reliability of those systems before being fixed. +In our previous work, we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to misunderstanding where the implicit unlock is called, including 30 double locks and seven deadlocks caused by acquiring locks in conflicting orders. Those deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They all are from famous Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox), and severely hurt the reliability of those systems before being fixed. -A brief description of the project. - * An indication of how you will integrate this project into Substrate / Polkadot / Kusama. - * An indication of why your team is interested in creating this project. +A brief description of the project.We propose to build an IDE tool for visualizing the lifetime scope of a user-selected variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting locking operations or function calls leading to locking operations. + + +How our tool will be integrated into Substrate/Polkadot? +Both Substrate and Polkadot are implemented in Rust. Previously, double locks or deadlocks due to acquiring locks in conflicting orders were identified and fixed in Substrate [1, 2]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [3, 4, 5]. We believe our tool can prevent Substrate/Polkadot programmers from making similar mistakes in the future. + + +Why we are interested in creating this project? +We are interested in building the tool due to three reasons. First, our previous empirical study shows that deadlocks due to misunderstanding Rust’s lifetime rules are common bugs in Rust programs. Visualizing lifetime can avoid these bugs during development, benefiting the whole Rust community. Second, misunderstanding Rust’s lifetime rules can also cause memory bugs, such as use-after-free and double free. Thus, the proposed tool has the potential to combat memory bugs. Third, the experience of building the proposed tool can inspire similar tools for other programming languages featuring lifetime (e.g., Kotlin). + + +[1] https://github.com/paritytech/substrate/pull/197 +[2] https://github.com/paritytech/substrate/pull/6225/commits/61e3b8d53674687790d2b30bc450cd59e09f563d +[3] https://github.com/paritytech/parity-db/pull/8 +[4] https://github.com/paritytech/substrate/pull/6277 +[5] https://github.com/paritytech/parity-common/pull/396 + ### Project Details We expect the teams to already have a solid idea about the project's expected final state. From 968562ea6f387a68311c31c2de5b4ce4a8bde158 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 21:13:06 -0400 Subject: [PATCH 03/21] finish description --- grants/speculative/visualize_rust_lifetime.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 7a0901463..d3ea6ce35 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -27,9 +27,13 @@ We are interested in building the tool due to three reasons. First, our previous [1] https://github.com/paritytech/substrate/pull/197 + [2] https://github.com/paritytech/substrate/pull/6225/commits/61e3b8d53674687790d2b30bc450cd59e09f563d + [3] https://github.com/paritytech/parity-db/pull/8 + [4] https://github.com/paritytech/substrate/pull/6277 + [5] https://github.com/paritytech/parity-common/pull/396 From 3a523f00338283a5c390fbc9a2deae367911c8b5 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 21:15:02 -0400 Subject: [PATCH 04/21] finish the second part --- grants/speculative/visualize_rust_lifetime.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index d3ea6ce35..4bd7cadde 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -38,14 +38,17 @@ We are interested in building the tool due to three reasons. First, our previous ### Project Details -We expect the teams to already have a solid idea about the project's expected final state. - -Therefore, we ask the teams to submit (where relevant): -* Mockups/designs of any UI components -* API specifications of the core functionality -* An overview of the technology stack to be used -* Documentation of core components, protocols, architecture etc. to be deployed -* PoC/MVP or other relevant prior work or research on the topic + +We have built a prototype of the proposed tool. We published a demonstration paper at this year’s CCS to describe the prototype. The paper can be found here: https://songlh.github.io/paper/vr.pdf. We also recorded a video to explain the prototype, and the video can be found here: https://youtu.be/L5F_XCOrJTQ. + +We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. One is in Substrate. The other three are in the dependent libraries of Substrate or Polkadot. We reported all the detected bugs. All of them were fixed by developers based on our reporting. The information of the detected bugs is listed as follows: + +https://github.com/paritytech/parity-db/pull/8 + +https://github.com/paritytech/substrate/pull/6277 + +https://github.com/paritytech/parity-common/pull/396 + ### Ecosystem Fit Are there any other projects similar to yours? If so, how is your project different? From e173da1b71f73cb8a142f1b3e550e60133b73df9 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 21:20:13 -0400 Subject: [PATCH 05/21] finish the second part --- grants/speculative/visualize_rust_lifetime.md | 26 +++++++++++++------ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 4bd7cadde..861ab1b88 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -51,30 +51,40 @@ https://github.com/paritytech/parity-common/pull/396 ### Ecosystem Fit -Are there any other projects similar to yours? If so, how is your project different? +There is no existing project similar to ours. ## Team :busts_in_silhouette: ### Team members -* Name of team leader -* Names of team members +* Name of team leader: Linhai Song +* Names of team members: Linhai Song, Yiying Zhang, and Ziyi Zhang ### Team Website -* https:// +* Linhai Song’s homepage: https://songlh.github.io/ +* Yiying Zhang’s homepage: https://cseweb.ucsd.edu/~yiying/ + ### Legal Structure -Please provide the name and registered address of the legal entity executing the project. When applying via the General Grants program, these details can also be shared privately via the Google Form used for your application. +XXXX ### Team's experience -Please describe the team's relevant experience. If the project involves development work, then we'd appreciated if you can single out a few interesting code commits made by team members on their past projects. For research-related grants, references to past publications and projects in a related domain are helpful. + +The team conducted an empirical study on real-world memory bugs and concurrency bugs in Rust, which was published in PLDI’2020. Through this project, the team has built on a comprehensive understanding of common errors made by programmers when coding Rust. + +The team built a prototype for the proposed tool, and the prototype was published in the demonstration track of CCS’2020. This experience demonstrates that the team is capable to build the proposed technique. + +Team member Linhai Song has 10 years of expertise in programming analysis, and has published at top programming languages and software engineering conferences (e.g., PLDI, ICSE, FSE, OOPSLA). + +Team member Yiying Zhang has conducted various systems research with papers published at OSDI and SOSP. ### Team Code Repos * https://github.com/ * https://github.com/ ### Team LinkedIn Profiles -* https://www.linkedin.com/ -* https://www.linkedin.com/ +* Linhai Song: https://www.linkedin.com/in/linhai-song-7a3b12120/ +* Yiying Zhang: https://www.linkedin.com/in/yiyingzhang/ + ## Development Roadmap :nut_and_bolt: From ded6e686d9d6124a75ab93b0ec2dafba4fa3ed03 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 22:27:13 -0400 Subject: [PATCH 06/21] begin to write roadmap --- grants/speculative/visualize_rust_lifetime.md | 41 ++++++++++++------- 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 861ab1b88..e70f63a12 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -78,8 +78,9 @@ Team member Linhai Song has 10 years of expertise in programming analysis, and h Team member Yiying Zhang has conducted various systems research with papers published at OSDI and SOSP. ### Team Code Repos -* https://github.com/ -* https://github.com/ +* LDoctor (ICSE ‘17): https://github.com/songlh/LDoctor +* Rust-Study (PLDI ‘20): https://github.com/system-pclub/rust-study +* LegoOS (OSDI ‘18): https://github.com/WukLab/LegoOS ### Team LinkedIn Profiles * Linhai Song: https://www.linkedin.com/in/linhai-song-7a3b12120/ @@ -88,22 +89,14 @@ Team member Yiying Zhang has conducted various systems research with papers publ ## Development Roadmap :nut_and_bolt: -This section should break out the development roadmap into a number of milestones. Since the milestones will appear in the grant contract, it helps to describe the functionality we should expect, plus how we can check that such functionality exists in the product. Whenever milestones are delivered, we refer to the contract to ensure that everything has been delivered as expected. +### Overview -Below we provide an **example roadmap**. In the descriptions it should be clear how the project is related to Substrate and/or Polkadot. We recommend that the scope of the work can fit within a 3 month period and that teams structure their roadmap as 1 month = 1 milestone. +We will build the proposed tool as a plugin of VSCode and implement the proposed program analysis by analyzing Rust’s MIR. We divide the project into three milestones. We aim to finish the whole project in three months and achieve a milestone in each month. -For each milestone: -* Please be sure to include a specification of the software. The level of detail must be enough so that we are able to verify that the software meets the specification. -* Please include total amount of funding requested per milestone. -* Please note that we require documentation (e.g. tutorials, API specifications, architecture details) in each milestone. This ensures that the code can be widely used by the community. -* Please provide a test suite, comprising unit and integration tests, along with a guide on how to run these. -* Please commit to providing a dockerfiles for the delivery of your project. -* Please indicate the milestone duration, as well as number of Full-Time Employees working on each milestone, and include the number of days along with their cost per day. +* **Total Estimated Duration:** 3 months +* **Full-time equivalent (FTE):** 3 +* **Total Costs:** Financial information will be disclosed privately. -### Overview -* **Total Estimated Duration:** Duration of the whole project -* **Full-time equivalent (FTE):** Workload of an employed person ([see](https://en.wikipedia.org/wiki/Full-time_equivalent)) -* **Total Costs:** Amount of Payment for the whole project. The total amount of funding needs to be below $100k. ### Milestone 1 Example — Implement Substrate Modules * **Estimated Duration:** 1 month @@ -121,6 +114,24 @@ For each milestone: | 4. | Substrate chain | Modules X, Y & Z of our custom chain will interact in such a way... (Please describe the deliverable here as detailed as possible) | | 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain | + +### Milestone 1 Example — Implement Substrate Modules +* **Estimated Duration:** 1 month +* **FTE:** 1 +* **Costs:** $5,000 + +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| 0a. | License | Apache 2.0 / MIT / Unlicense | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | +| 0c. | Testing Guide | The code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | +| 1. | Substrate module: X | We will create a Substrate module that will... (Please list the functionality that will be coded for the first milestone) | +| 2. | Substrate module: Y | We will create a Substrate module that will... | +| 3. | Substrate module: Z | We will create a Substrate module that will... | +| 4. | Substrate chain | Modules X, Y & Z of our custom chain will interact in such a way... (Please describe the deliverable here as detailed as possible) | +| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain | + + ### Milestone 2 Example — Additional features ... From 1fc35d16fc8cef930de86f434434f8e552cb5998 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 23:03:49 -0400 Subject: [PATCH 07/21] finish milestone 2 --- grants/speculative/visualize_rust_lifetime.md | 42 +++++++++---------- 1 file changed, 19 insertions(+), 23 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index e70f63a12..49595176a 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -95,41 +95,37 @@ We will build the proposed tool as a plugin of VSCode and implement the proposed * **Total Estimated Duration:** 3 months * **Full-time equivalent (FTE):** 3 -* **Total Costs:** Financial information will be disclosed privately. +* **Total Costs:** financial information will be disclosed privately. -### Milestone 1 Example — Implement Substrate Modules +### Milestone 1 — Implement the bug detection component * **Estimated Duration:** 1 month -* **FTE:** 1 -* **Costs:** $5,000 + | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 0a. | License | Apache 2.0 / MIT / Unlicense | -| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | -| 0c. | Testing Guide | The code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | -| 1. | Substrate module: X | We will create a Substrate module that will... (Please list the functionality that will be coded for the first milestone) | -| 2. | Substrate module: Y | We will create a Substrate module that will... | -| 3. | Substrate module: Z | We will create a Substrate module that will... | -| 4. | Substrate chain | Modules X, Y & Z of our custom chain will interact in such a way... (Please describe the deliverable here as detailed as possible) | -| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to run the bug detection component as a standalone tool on terminal. | +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing deadlocks to demonstrate the bug detection capability. We will also run this component on the latest version of Substrate, Polkadot, and ink!. We will manually inspect all reported results to count the number of bugs and the number of false positives. | +| 1. | Double-Lock Detection Module | We will implement a double-lock detector based on interpreting a Rust program’s MIR. | +| 2. | Conflicting-Lock Detection Module | We will implement a detector that can identify deadlocks due to acquiring locks in conflicting orders through analyzing the MIR of Rust programs.| +| 3. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | -### Milestone 1 Example — Implement Substrate Modules +### Milestone 2 — Implement the visualization component * **Estimated Duration:** 1 month -* **FTE:** 1 -* **Costs:** $5,000 + | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 0a. | License | Apache 2.0 / MIT / Unlicense | -| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | -| 0c. | Testing Guide | The code will have proper unit-test coverage (e.g. 90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | -| 1. | Substrate module: X | We will create a Substrate module that will... (Please list the functionality that will be coded for the first milestone) | -| 2. | Substrate module: Y | We will create a Substrate module that will... | -| 3. | Substrate module: Z | We will create a Substrate module that will... | -| 4. | Substrate chain | Modules X, Y & Z of our custom chain will interact in such a way... (Please describe the deliverable here as detailed as possible) | -| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to install and use the visualization component in VSCode. | +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs to test whether variables’ lifetime is correctly computed, whether variables’ lifetime is correctly visualized, whether locking operations are correctly identified, and whether locking operations are correctly highlighted. | +| 1. | Lifetime Computation Module | We will compute the lifetime for each variable in a Rust program by interpreting the program’s MIR. | +| 2. | Lifetime Visualization Module | We will visualize the computed lifetime of a user-selected variable.| +| 3. | Locking Operation Identification Module | We will identify locking operations or function calls that may lead to locking operations by conducting inter-procedural analysis. | +| 4. | Locking Operation Highlighting Module | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified locking operations in the selected critical section. | +| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component | ### Milestone 2 Example — Additional features From 9332c750beb9df9948174d84bea20e17a2ebf9f4 Mon Sep 17 00:00:00 2001 From: Linhai Date: Tue, 29 Sep 2020 23:09:41 -0400 Subject: [PATCH 08/21] finish milestone 2 --- grants/speculative/visualize_rust_lifetime.md | 45 +++++++++++++++---- 1 file changed, 36 insertions(+), 9 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 49595176a..53b1e330e 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -125,25 +125,52 @@ We will build the proposed tool as a plugin of VSCode and implement the proposed | 2. | Lifetime Visualization Module | We will visualize the computed lifetime of a user-selected variable.| | 3. | Locking Operation Identification Module | We will identify locking operations or function calls that may lead to locking operations by conducting inter-procedural analysis. | | 4. | Locking Operation Highlighting Module | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified locking operations in the selected critical section. | -| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component | +| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | -### Milestone 2 Example — Additional features -... +### Milestone 3 — Integrate the bug detection component with the visualization component +* **Estimated Duration:** 1 month + -### Community engagement +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to use the tool. | +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing deadlocks to demonstrate the buggy locking operations are correctly identified and highlighted. | +| 1. | Integrating the Two Components | We will integrate the bug detection component with the visualization component. | +| 2. | Tutorial Writing | We will write a tutorial and record a video to explain how to use our tool.| +| 3. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | -As part of the Program, we require that you produce an article/tutorial and publish it (for example on [Medium](https://medium.com/)). It should explain your work done as part of the grant. -Normally, we ask you to submit the write-up upon the completion of your grant, although for larger projects it might make sense to publish multiple articles after the completion of different milestones. ## Future Plans -Please include the team's long-term plans and intentions. + +In the future, we plan to extend the proposed tool along two directions. + +First, we will extend the proposed tool to cover memory bugs. Our previous empirical study showed that there are also memory bugs due to misunderstanding Rust’s lifetime rules, such as use-after-free bugs and double-free bugs. The proposed tool has the potential to help Rust programmers avoid these bugs. Of course, we need to explore what program elements should be visualized for memory bugs. + +Second, we will conduct a survey to understand what challenges are faced by programmers when understanding Rust’s lifetime rules and whether the proposed tool can really help them avoid deadlocks. The survey results will guide us to improve the proposed tool, and broadly speaking, the evolution of Rust. + ## Additional Information :heavy_plus_sign: -Any additional information that you think is relevant to this application that hasn't already been included. -Possible additional information to include: * What work has been done so far? + +We have built a prototype of the proposed tool. We wrote one paper (https://songlh.github.io/paper/vr.pdf) and recorded one video (https://youtu.be/L5F_XCOrJTQ) to describe the prototype. + +We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. We reported all the detected bugs and all of them were fixed based on our reporting [1, 2, 3]. + +[1] https://github.com/paritytech/parity-db/pull/8 + +[2] https://github.com/paritytech/substrate/pull/6277 + +[3] https://github.com/paritytech/parity-common/pull/396 + + * Are there are any teams who have already contributed (financially) to the project? + +No + * Have you applied for other grants so far? + +No \ No newline at end of file From 188d5ff45dc81f69833fc2f29064a42aa80e66f7 Mon Sep 17 00:00:00 2001 From: songlh Date: Sun, 4 Oct 2020 15:32:39 -0400 Subject: [PATCH 09/21] proofreading section 1 --- grants/speculative/visualize_rust_lifetime.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 53b1e330e..2b4043354 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -12,18 +12,20 @@ Rust’s compiler checks are based on a suite of ownership and lifetime rules. T However, Rust’s lifetime rules are unique and complex. It is challenging for Rust programmers to infer where a variable’s lifetime ends. Therefore, it is not uncommon for them to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers’ expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to double-lock deadlocks or deadlocks due to acquiring locks in conflicting orders. -In our previous work, we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to misunderstanding where the implicit unlock is called, including 30 double locks and seven deadlocks caused by acquiring locks in conflicting orders. Those deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They all are from famous Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox), and severely hurt the reliability of those systems before being fixed. +In our previous work, we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to misunderstanding where the implicit Unlock() is called, including 30 double locks and seven deadlocks caused by acquiring locks in conflicting orders. Those deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They are all from famous Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox), and severely hurt the reliability of those systems before being fixed. -A brief description of the project.We propose to build an IDE tool for visualizing the lifetime scope of a user-selected variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting locking operations or function calls leading to locking operations. - +A brief description of the project. +We propose to build an IDE tool for visualizing the lifetime scope of a user-selected variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting locking operations or function calls leading to locking operations. How our tool will be integrated into Substrate/Polkadot? -Both Substrate and Polkadot are implemented in Rust. Previously, double locks or deadlocks due to acquiring locks in conflicting orders were identified and fixed in Substrate [1, 2]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [3, 4, 5]. We believe our tool can prevent Substrate/Polkadot programmers from making similar mistakes in the future. +Both Substrate and Polkadot are implemented in Rust. Previously, double locks or deadlocks due to acquiring locks in conflicting orders were identified and fixed in Substrate [1, 2]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [3, 4, 5]. We believe our tool can prevent Substrate/Polkadot programmers from making similar mistakes again in the future. + + +Why are we interested in creating this project? +We are interested in building the tool due to three reasons. First, our previous empirical study shows that deadlocks due to misunderstanding Rust’s lifetime rules are common in Rust programs. Visualizing lifetime can avoid these bugs during development, benefiting the whole Rust community. Second, misunderstanding Rust’s lifetime rules can also cause memory bugs, such as use-after-free and double free. Thus, the proposed tool has the potential to combat memory bugs. Third, the experience of building the proposed tool can inspire similar tools for other programming languages featuring lifetime (e.g., Kotlin). -Why we are interested in creating this project? -We are interested in building the tool due to three reasons. First, our previous empirical study shows that deadlocks due to misunderstanding Rust’s lifetime rules are common bugs in Rust programs. Visualizing lifetime can avoid these bugs during development, benefiting the whole Rust community. Second, misunderstanding Rust’s lifetime rules can also cause memory bugs, such as use-after-free and double free. Thus, the proposed tool has the potential to combat memory bugs. Third, the experience of building the proposed tool can inspire similar tools for other programming languages featuring lifetime (e.g., Kotlin). [1] https://github.com/paritytech/substrate/pull/197 @@ -37,6 +39,8 @@ We are interested in building the tool due to three reasons. First, our previous [5] https://github.com/paritytech/parity-common/pull/396 + + ### Project Details We have built a prototype of the proposed tool. We published a demonstration paper at this year’s CCS to describe the prototype. The paper can be found here: https://songlh.github.io/paper/vr.pdf. We also recorded a video to explain the prototype, and the video can be found here: https://youtu.be/L5F_XCOrJTQ. From 44d057dd7eab10683f355b9d177ecdfcb0c79381 Mon Sep 17 00:00:00 2001 From: songlh Date: Sun, 4 Oct 2020 15:41:39 -0400 Subject: [PATCH 10/21] proofreading section 2 --- grants/speculative/visualize_rust_lifetime.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 2b4043354..e4e7d0b0c 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -54,6 +54,7 @@ https://github.com/paritytech/substrate/pull/6277 https://github.com/paritytech/parity-common/pull/396 + ### Ecosystem Fit There is no existing project similar to ours. @@ -69,18 +70,19 @@ There is no existing project similar to ours. ### Legal Structure -XXXX +Information of our legal structure will be disclosed privately. ### Team's experience -The team conducted an empirical study on real-world memory bugs and concurrency bugs in Rust, which was published in PLDI’2020. Through this project, the team has built on a comprehensive understanding of common errors made by programmers when coding Rust. +The team conducted an empirical study on memory bugs and concurrency bugs in real-world Rust programs. The study was published in PLDI’2020. Through this project, the team has built a comprehensive understanding of common errors made by programmers when coding Rust. -The team built a prototype for the proposed tool, and the prototype was published in the demonstration track of CCS’2020. This experience demonstrates that the team is capable to build the proposed technique. +The team built a prototype for the proposed tool. The prototype was published in the demonstration track of CCS’2020, demonstrating the team’s capability to build the proposed technique. Team member Linhai Song has 10 years of expertise in programming analysis, and has published at top programming languages and software engineering conferences (e.g., PLDI, ICSE, FSE, OOPSLA). Team member Yiying Zhang has conducted various systems research with papers published at OSDI and SOSP. + ### Team Code Repos * LDoctor (ICSE ‘17): https://github.com/songlh/LDoctor * Rust-Study (PLDI ‘20): https://github.com/system-pclub/rust-study From 6887d0ad8fab483d3f959ba3fc81d078de202f90 Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 22:39:50 -0400 Subject: [PATCH 11/21] section 1 --- grants/speculative/visualize_rust_lifetime.md | 30 +++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 53b1e330e..e2f5b23a5 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -6,35 +6,35 @@ ### Overview -Rust is a new programming language designed to provide both safety guarantees like high-level languages and performance guarantees like low-level languages. To achieve this design purpose, Rust leverages static compiler checks to rule out severe memory and thread safety issues during compilation. At runtime, Rust behaves like C/C++ and provides performance as good as C/C++. Due to its safety and performance, Rust is increasingly adopted to build safety-critical software, such as OSes and browsers. Rust is also used to implement many software systems in the Web3 technology stack (e.g., substrate, polkadot, ink!). +Rust is a new programming language designed to provide both safety guarantees that are like high-level languages and performance guarantees that are like low-level languages. To achieve this design purpose, Rust leverages static compiler checks to rule out severe memory and thread safety issues at the compilation time. At runtime, Rust behaves like C/C++ and could deliver performance that is as good as C/C++. Due to its safety and performance benefits, Rust has seen increasing adoption in building low-level systems software, such as OSs and browsers. Rust is also used to implement many software systems in the Web3 technology stack (e.g., substrate, polkadot, ink!). -Rust’s compiler checks are based on a suite of ownership and lifetime rules. The basic rule allows one value to only have one owner variable, and the value is dropped (freed) when its owner variable ends its lifetime. Rust extends the basic rule to allow ownership to be moved and borrowed, but still guarantees all accesses to a value are within its owner variable’s lifetime scope. Besides safety checks, lifetime is also used for automated resource management. For example, there is no explicit Unlock() in Rust. A locking function call returns a reference of the protected variable, and when the reference ends its lifetime, Rust automatically releases the acquired lock (by implicitly calling Unlock()) to avoid lock-without-unlock bugs in C/C++. +Rust's compiler checks are based on a suite of ownership and lifetime rules. The basic rule allows one value to only have one owner variable, and the value is dropped (freed) when its owner variable ends its lifetime. Rust extends the basic rule to allow ownership to be moved and borrowed, while still guaranteeing all accesses to a value to be within its owner variable’s lifetime scope. Besides safety checks, lifetime is also used for automated resource management. For example, there is no explicit Unlock() in Rust. A Lock() function call returns a reference of the protected variable, and when the reference ends its lifetime, Rust automatically releases the acquired lock (by implicitly calling Unlock()). -However, Rust’s lifetime rules are unique and complex. It is challenging for Rust programmers to infer where a variable’s lifetime ends. Therefore, it is not uncommon for them to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers’ expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to double-lock deadlocks or deadlocks due to acquiring locks in conflicting orders. +Rust's lifetime rules are complex and different from all other existing languages. It is challenging for Rust programmers to infer where a variable's lifetime ends. As a result, it is not uncommon for programmers to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers' expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to double lock or lock in conflicting orders. -In our previous work, we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to misunderstanding where the implicit unlock is called, including 30 double locks and seven deadlocks caused by acquiring locks in conflicting orders. Those deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They all are from famous Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox), and severely hurt the reliability of those systems before being fixed. - - -A brief description of the project.We propose to build an IDE tool for visualizing the lifetime scope of a user-selected variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting locking operations or function calls leading to locking operations. +In our previous work [1], we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to the misunderstanding of where the implicit Unlock() is called, including 30 double locks and seven locks acquired in conflicting orders. These deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They are all from popular Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox) and have severely hurt the reliability of those systems before they were fixed. +A brief description of the project. +We propose to build an IDE tool for visualizing the lifetime scope of a user-selected variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting blocking operations or function calls leading to blocking operations. How our tool will be integrated into Substrate/Polkadot? -Both Substrate and Polkadot are implemented in Rust. Previously, double locks or deadlocks due to acquiring locks in conflicting orders were identified and fixed in Substrate [1, 2]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [3, 4, 5]. We believe our tool can prevent Substrate/Polkadot programmers from making similar mistakes in the future. +Both Substrate and Polkadot are implemented in Rust. Previously, double locks or locks in conflicting orders were fixed in Substrate [2, 3]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [4, 5, 6]. We believe our tool can effectively prevent Substrate/Polkadot programmers from making similar mistakes and other types of mistakes our tool will reveal. +Why are we interested in creating this project? +We are interested in building the tool due to three reasons. First, our previous empirical study shows that deadlocks due to the misunderstanding of Rust's lifetime rules are common in Rust programs. Visualizing lifetime can avoid these bugs during the development stage, benefiting the whole Rust community. Second, the misunderstanding of Rust's lifetime rules can also cause memory bugs such as use-after-free and double free. Thus, the proposed tool has the potential to combat memory bugs. Third, the experience of building the proposed tool can inspire similar tools for other programming languages featuring lifetime (e.g., Kotlin). -Why we are interested in creating this project? -We are interested in building the tool due to three reasons. First, our previous empirical study shows that deadlocks due to misunderstanding Rust’s lifetime rules are common bugs in Rust programs. Visualizing lifetime can avoid these bugs during development, benefiting the whole Rust community. Second, misunderstanding Rust’s lifetime rules can also cause memory bugs, such as use-after-free and double free. Thus, the proposed tool has the potential to combat memory bugs. Third, the experience of building the proposed tool can inspire similar tools for other programming languages featuring lifetime (e.g., Kotlin). +[1] Boqin Qin, Yilun Chen, Zeming Yu, Linhai Song, and Yiying Zhang. “Understanding Memory and Thread Safety Practices and Issues in Real-World Rust Programs.” In PLDI'2020. -[1] https://github.com/paritytech/substrate/pull/197 +[2] https://github.com/paritytech/substrate/pull/197 -[2] https://github.com/paritytech/substrate/pull/6225/commits/61e3b8d53674687790d2b30bc450cd59e09f563d +[3] https://github.com/paritytech/substrate/pull/6225/commits/61e3b8d53674687790d2b30bc450cd59e09f563d -[3] https://github.com/paritytech/parity-db/pull/8 +[4] https://github.com/paritytech/parity-db/pull/8 -[4] https://github.com/paritytech/substrate/pull/6277 +[5] https://github.com/paritytech/substrate/pull/6277 -[5] https://github.com/paritytech/parity-common/pull/396 +[6] https://github.com/paritytech/parity-common/pull/396 ### Project Details From ee3bf16d1cf9efb1c925e0b9b4936e826b5b1913 Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 22:44:54 -0400 Subject: [PATCH 12/21] project details --- grants/speculative/visualize_rust_lifetime.md | 22 ++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 22e08a8ca..8a0ad87cb 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -42,15 +42,27 @@ We are interested in building the tool due to three reasons. First, our previous ### Project Details -We have built a prototype of the proposed tool. We published a demonstration paper at this year’s CCS to describe the prototype. The paper can be found here: https://songlh.github.io/paper/vr.pdf. We also recorded a video to explain the prototype, and the video can be found here: https://youtu.be/L5F_XCOrJTQ. +What have we already done? +We have built a prototype of the proposed tool. Our prototype can visualize a selected variable and conduct double-lock detection. We published a demonstration paper at this year’s CCS to describe the prototype. The paper can be found [here](https://songlh.github.io/paper/vr.pdf). We also recorded a video to explain the prototype, and the video can be found [here](https://youtu.be/L5F_XCOrJTQ). -We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. One is in Substrate. The other three are in the dependent libraries of Substrate or Polkadot. We reported all the detected bugs. All of them were fixed by developers based on our reporting. The information of the detected bugs is listed as follows: -https://github.com/paritytech/parity-db/pull/8 +We applied the double-lock detection component to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. One is in Substrate. The other three are in the dependent libraries of Substrate or Polkadot. We reported all the detected bugs. All of them were fixed by developers based on our reporting. The information of the detected bugs is listed as follows: -https://github.com/paritytech/substrate/pull/6277 +[pr-1] https://github.com/paritytech/parity-db/pull/8 + +[pr-2] https://github.com/paritytech/substrate/pull/6277 + +[pr-3] https://github.com/paritytech/parity-common/pull/396 + +What are we going to do? +We propose to extend the prototype along three directions: + +First, we will add the bug detection functionality for more deadlock types. Specifically, we will add the detection of locks with conflicting orders and misuse of mutex and non-mutex synchronization primitives (e.g., channel, conditional variable). + +Second, we will identify and visualize more blocking operations that can potentially lead to deadlocks in a selected critical section such as receiving from a channel and waiting on a conditional variable. + +Third, we will integrate the above bug detection and visualization functionalities and document our tool. -https://github.com/paritytech/parity-common/pull/396 From 6e80b1985a8176a8405b38849661d7de14d393e3 Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 22:47:56 -0400 Subject: [PATCH 13/21] change link --- grants/speculative/visualize_rust_lifetime.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 8a0ad87cb..5845f90f9 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -43,16 +43,16 @@ We are interested in building the tool due to three reasons. First, our previous ### Project Details What have we already done? -We have built a prototype of the proposed tool. Our prototype can visualize a selected variable and conduct double-lock detection. We published a demonstration paper at this year’s CCS to describe the prototype. The paper can be found [here](https://songlh.github.io/paper/vr.pdf). We also recorded a video to explain the prototype, and the video can be found [here](https://youtu.be/L5F_XCOrJTQ). +We have built a prototype of the proposed tool. Our prototype can visualize a selected variable and conduct double-lock detection. We published a demonstration paper at this year's CCS to describe the prototype. The paper can be found [here](https://songlh.github.io/paper/vr.pdf). We also recorded a video to explain the prototype, and the video can be found [here](https://youtu.be/L5F_XCOrJTQ). We applied the double-lock detection component to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. One is in Substrate. The other three are in the dependent libraries of Substrate or Polkadot. We reported all the detected bugs. All of them were fixed by developers based on our reporting. The information of the detected bugs is listed as follows: -[pr-1] https://github.com/paritytech/parity-db/pull/8 +[PR-1] https://github.com/paritytech/parity-db/pull/8 -[pr-2] https://github.com/paritytech/substrate/pull/6277 +[PR-2] https://github.com/paritytech/substrate/pull/6277 -[pr-3] https://github.com/paritytech/parity-common/pull/396 +[PR-3] https://github.com/paritytech/parity-common/pull/396 What are we going to do? We propose to extend the prototype along three directions: From fa03df24b000fe40703b78fc084c53164ba35dfa Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 23:04:39 -0400 Subject: [PATCH 14/21] check in group members --- grants/speculative/visualize_rust_lifetime.md | 24 ++++++++++++------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 5845f90f9..33912b899 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -76,8 +76,8 @@ There is no existing project similar to ours. * Names of team members: Linhai Song, Yiying Zhang, and Ziyi Zhang ### Team Website -* Linhai Song’s homepage: https://songlh.github.io/ -* Yiying Zhang’s homepage: https://cseweb.ucsd.edu/~yiying/ +* [Linhai Song’s homepage](https://songlh.github.io/) +* [Yiying Zhang’s homepage](https://cseweb.ucsd.edu/~yiying/) ### Legal Structure @@ -85,9 +85,11 @@ Information of our legal structure will be disclosed privately. ### Team's experience -The team conducted an empirical study on memory bugs and concurrency bugs in real-world Rust programs. The study was published in PLDI’2020. Through this project, the team has built a comprehensive understanding of common errors made by programmers when coding Rust. +The team conducted an empirical study on memory bugs and concurrency bugs in real-world Rust programs. The study was published in PLDI'2020. Through this project, the team has built a comprehensive understanding of common errors made by programmers when coding Rust. -The team built a prototype for the proposed tool. The prototype was published in the demonstration track of CCS’2020, demonstrating the team’s capability to build the proposed technique. +The team built a prototype for the proposed tool. The prototype was published in the demonstration track of CCS'2020, demonstrating the team's capability to build the proposed technique. + +The team has another research paper on understanding concurrency bugs in Go published in ASPLOS'2019. The team has more than three years' research experience on concurrency bugs. Team member Linhai Song has 10 years of expertise in programming analysis, and has published at top programming languages and software engineering conferences (e.g., PLDI, ICSE, FSE, OOPSLA). @@ -95,13 +97,17 @@ Team member Yiying Zhang has conducted various systems research with papers publ ### Team Code Repos -* LDoctor (ICSE ‘17): https://github.com/songlh/LDoctor -* Rust-Study (PLDI ‘20): https://github.com/system-pclub/rust-study -* LegoOS (OSDI ‘18): https://github.com/WukLab/LegoOS +* [LDoctor (ICSE '17)](https://github.com/songlh/LDoctor) +* [Rust-Study (PLDI '20)](https://github.com/system-pclub/rust-study) +* [LegoOS (OSDI '18)](https://github.com/WukLab/LegoOS) +* [pDPM (ATC '20)](https://github.com/WukLab/pDPM) +* [Pythia (USENIX SEC '20)](https://github.com/WukLab/Pythia) +* [LITE (SOSP '17)](https://github.com/WukLab/LITE) +* [Hotpot (SoCC '17)](https://github.com/WukLab/Hotpot) ### Team LinkedIn Profiles -* Linhai Song: https://www.linkedin.com/in/linhai-song-7a3b12120/ -* Yiying Zhang: https://www.linkedin.com/in/yiyingzhang/ +* [Linhai Song](https://www.linkedin.com/in/linhai-song-7a3b12120/) +* [Yiying Zhang](https://www.linkedin.com/in/yiyingzhang/) ## Development Roadmap :nut_and_bolt: From 8c4cc242ad1e7b6827c2c12ebc379384040b0076 Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 23:09:41 -0400 Subject: [PATCH 15/21] milestone 1 --- grants/speculative/visualize_rust_lifetime.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 33912b899..97688eceb 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -114,7 +114,10 @@ Team member Yiying Zhang has conducted various systems research with papers publ ### Overview -We will build the proposed tool as a plugin of VSCode and implement the proposed program analysis by analyzing Rust’s MIR. We divide the project into three milestones. We aim to finish the whole project in three months and achieve a milestone in each month. +We will build the proposed tool as a plugin of [VSCode](https://github.com/microsoft/vscode), which is an open-source IDE project. We will implement the proposed program analysis by analyzing Rust’s MIR. + +We divide the project into three milestones. We aim to finish the whole project in three months and achieve a milestone in each month. + * **Total Estimated Duration:** 3 months * **Full-time equivalent (FTE):** 3 @@ -128,11 +131,14 @@ We will build the proposed tool as a plugin of VSCode and implement the proposed | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to run the bug detection component as a standalone tool on terminal. | -| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing deadlocks to demonstrate the bug detection capability. We will also run this component on the latest version of Substrate, Polkadot, and ink!. We will manually inspect all reported results to count the number of bugs and the number of false positives. | -| 1. | Double-Lock Detection Module | We will implement a double-lock detector based on interpreting a Rust program’s MIR. | -| 2. | Conflicting-Lock Detection Module | We will implement a detector that can identify deadlocks due to acquiring locks in conflicting orders through analyzing the MIR of Rust programs.| -| 3. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to run the bug detection component as a standalone tool on terminal.| +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. + +We will also include 10 toy programs containing different types of deadlocks to demonstrate the bug detection capability. We will also run this component on the latest version of Substrate, Polkadot, and ink!. We will manually inspect all reported results to count the number of bugs and the number of false positives. | +| 1. | Detecting Conflicting Locks | We will implement a detector that can identify deadlocks due to locks in conflicting orders through analyzing the MIR of Rust programs.| +| 2. | Detecting Misuse of Mutex and Channel | We will implement a detector to identify deadlocks due to errors when using a mutex together with a channel. | +| 3. | Detecting Misuse of Mutex and Conditional Variable | We will implement a detector to identify deadlocks due to mistakes when using a mutex together with a conditional variable. | +| 4. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | ### Milestone 2 — Implement the visualization component From d4e59bced0a2030e307cbe8a62dfc16b8f831122 Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 23:10:21 -0400 Subject: [PATCH 16/21] milestone 1 --- grants/speculative/visualize_rust_lifetime.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 97688eceb..39a456d67 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -132,9 +132,7 @@ We divide the project into three milestones. We aim to finish the whole project | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to run the bug detection component as a standalone tool on terminal.| -| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. - -We will also include 10 toy programs containing different types of deadlocks to demonstrate the bug detection capability. We will also run this component on the latest version of Substrate, Polkadot, and ink!. We will manually inspect all reported results to count the number of bugs and the number of false positives. | +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing different types of deadlocks to demonstrate the bug detection capability. We will also run this component on the latest version of Substrate, Polkadot, and ink!. We will manually inspect all reported results to count the number of bugs and the number of false positives. | | 1. | Detecting Conflicting Locks | We will implement a detector that can identify deadlocks due to locks in conflicting orders through analyzing the MIR of Rust programs.| | 2. | Detecting Misuse of Mutex and Channel | We will implement a detector to identify deadlocks due to errors when using a mutex together with a channel. | | 3. | Detecting Misuse of Mutex and Conditional Variable | We will implement a detector to identify deadlocks due to mistakes when using a mutex together with a conditional variable. | From 2af66869e9e2b83fd815c9850872da8a7d8e0689 Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 23:13:48 -0400 Subject: [PATCH 17/21] milestone 1 --- grants/speculative/visualize_rust_lifetime.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 39a456d67..0e20835b6 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -139,19 +139,19 @@ We divide the project into three milestones. We aim to finish the whole project | 4. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | -### Milestone 2 — Implement the visualization component +### Milestone 2 — Implement the visualization component * **Estimated Duration:** 1 month | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to install and use the visualization component in VSCode. | -| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs to test whether variables’ lifetime is correctly computed, whether variables’ lifetime is correctly visualized, whether locking operations are correctly identified, and whether locking operations are correctly highlighted. | -| 1. | Lifetime Computation Module | We will compute the lifetime for each variable in a Rust program by interpreting the program’s MIR. | -| 2. | Lifetime Visualization Module | We will visualize the computed lifetime of a user-selected variable.| -| 3. | Locking Operation Identification Module | We will identify locking operations or function calls that may lead to locking operations by conducting inter-procedural analysis. | -| 4. | Locking Operation Highlighting Module | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified locking operations in the selected critical section. | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to install and use the visualization component in VSCode. | +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs to test whether channel operations are correctly identified, whether channel operations are correctly visualized, whether operations on conditional variables are correctly identified, and whether operations on conditional variables are correctly highlighted. | +| 1. | Channel Operation Identification Module | We will identify channel operations or function calls that may lead to channel operations by conducting inter-procedural analysis. | +| 2. | Channel Operation Highlighting Module | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified channel operations in the selected critical section. | +| 3. | Conditional Variable Operation Identification Module | We will identify operations on a conditional variable or function calls that may lead to operations on a conditional variable by conducting inter-procedural analysis. | +| 4. | Conditional Variable Operation Highlighting Module | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified operations on a conditional variable in the selected critical section. | | 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | From a682399a0a0916200410692b93d3e1ba36df475d Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 23:17:57 -0400 Subject: [PATCH 18/21] finish everything --- grants/speculative/visualize_rust_lifetime.md | 23 ++++++++++--------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 0e20835b6..4f04cee21 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -155,7 +155,7 @@ We divide the project into three milestones. We aim to finish the whole project | 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | -### Milestone 3 — Integrate the bug detection component with the visualization component +### Milestone 3 — Integrate the bug detection component with the visualization component * **Estimated Duration:** 1 month @@ -163,10 +163,10 @@ We divide the project into three milestones. We aim to finish the whole project | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to use the tool. | -| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing deadlocks to demonstrate the buggy locking operations are correctly identified and highlighted. | -| 1. | Integrating the Two Components | We will integrate the bug detection component with the visualization component. | -| 2. | Tutorial Writing | We will write a tutorial and record a video to explain how to use our tool.| -| 3. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing different types of deadlocks to demonstrate the buggy blocking operations are correctly identified and highlighted. | +| 1. | Integrating the Visualization Component with the Bug Detection Component | We will integrate the bug detection component with the visualization component. | +| 2. | Tutorial Writing | We will write a tutorial and record a video to explain how to use our tool. | +| 3. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | @@ -174,24 +174,25 @@ We divide the project into three milestones. We aim to finish the whole project In the future, we plan to extend the proposed tool along two directions. -First, we will extend the proposed tool to cover memory bugs. Our previous empirical study showed that there are also memory bugs due to misunderstanding Rust’s lifetime rules, such as use-after-free bugs and double-free bugs. The proposed tool has the potential to help Rust programmers avoid these bugs. Of course, we need to explore what program elements should be visualized for memory bugs. +First, we plan to extend the proposed tool to cover memory bugs. Our previous empirical study showed that there are also memory bugs due to misunderstanding Rust's lifetime rules, such as use-after-free bugs and double-free bugs. The proposed tool has the potential to help Rust programmers avoid these bugs. Of course, we need to explore what program elements should be visualized for memory bugs. + +Second, we plan to conduct a survey to understand what challenges programmers face when understanding Rust's lifetime rules and whether the proposed tool can really help them avoid deadlocks. The survey results will guide us on improving the proposed tool, and broadly speaking, the evolution of Rust. -Second, we will conduct a survey to understand what challenges are faced by programmers when understanding Rust’s lifetime rules and whether the proposed tool can really help them avoid deadlocks. The survey results will guide us to improve the proposed tool, and broadly speaking, the evolution of Rust. ## Additional Information :heavy_plus_sign: * What work has been done so far? -We have built a prototype of the proposed tool. We wrote one paper (https://songlh.github.io/paper/vr.pdf) and recorded one video (https://youtu.be/L5F_XCOrJTQ) to describe the prototype. +We have built a prototype of the proposed tool. We wrote [one paper](https://songlh.github.io/paper/vr.pdf) and recorded [one video](https://youtu.be/L5F_XCOrJTQ) to describe the prototype. We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. We reported all the detected bugs and all of them were fixed based on our reporting [1, 2, 3]. -[1] https://github.com/paritytech/parity-db/pull/8 +[PR-1] https://github.com/paritytech/parity-db/pull/8 -[2] https://github.com/paritytech/substrate/pull/6277 +[PR-2] https://github.com/paritytech/substrate/pull/6277 -[3] https://github.com/paritytech/parity-common/pull/396 +[PR-3] https://github.com/paritytech/parity-common/pull/396 * Are there are any teams who have already contributed (financially) to the project? From 5ea4d207cdeabaf8c03b95f3975abce2e84efdcb Mon Sep 17 00:00:00 2001 From: Linhai Date: Wed, 14 Oct 2020 23:18:33 -0400 Subject: [PATCH 19/21] finish everything --- grants/speculative/visualize_rust_lifetime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 4f04cee21..e5e620c15 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -186,7 +186,7 @@ Second, we plan to conduct a survey to understand what challenges programmers fa We have built a prototype of the proposed tool. We wrote [one paper](https://songlh.github.io/paper/vr.pdf) and recorded [one video](https://youtu.be/L5F_XCOrJTQ) to describe the prototype. -We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. We reported all the detected bugs and all of them were fixed based on our reporting [1, 2, 3]. +We applied the bug detection component of the prototype to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. We reported all the detected bugs and all of them were fixed based on our reporting [PR-1, PR-2, PR-3]. [PR-1] https://github.com/paritytech/parity-db/pull/8 From e8231de27acd1dec68ce17a87ab24f2482a96808 Mon Sep 17 00:00:00 2001 From: Linhai Song Date: Thu, 4 Mar 2021 15:31:36 +0800 Subject: [PATCH 20/21] change the milestones --- grants/speculative/visualize_rust_lifetime.md | 57 ++++++++++--------- 1 file changed, 31 insertions(+), 26 deletions(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index e5e620c15..07aa7dac2 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -8,17 +8,18 @@ Rust is a new programming language designed to provide both safety guarantees that are like high-level languages and performance guarantees that are like low-level languages. To achieve this design purpose, Rust leverages static compiler checks to rule out severe memory and thread safety issues at the compilation time. At runtime, Rust behaves like C/C++ and could deliver performance that is as good as C/C++. Due to its safety and performance benefits, Rust has seen increasing adoption in building low-level systems software, such as OSs and browsers. Rust is also used to implement many software systems in the Web3 technology stack (e.g., substrate, polkadot, ink!). -Rust's compiler checks are based on a suite of ownership and lifetime rules. The basic rule allows one value to only have one owner variable, and the value is dropped (freed) when its owner variable ends its lifetime. Rust extends the basic rule to allow ownership to be moved and borrowed, while still guaranteeing all accesses to a value to be within its owner variable's lifetime scope. Besides safety checks, lifetime is also used for automated resource management. For example, there is no explicit Unlock() in Rust. A Lock() function call returns a reference of the protected variable, and when the reference ends its lifetime, Rust automatically releases the acquired lock (by implicitly calling Unlock()). +Rust's compiler checks are based on a suite of ownership and lifetime rules. The basic rule allows one value to only have one owner variable, and the value is dropped (freed) when its owner variable ends its lifetime. Rust extends the basic rule to allow ownership to be moved and borrowed, while still guaranteeing all accesses to a value to be within its owner variable's lifetime scope. Besides safety checks, lifetime is also used for automated resource management. For example, there is no explicit Unlock() in Rust. A Lock() function call returns a reference to the protected variable, and when the reference ends its lifetime, Rust automatically releases the acquired lock (by implicitly calling Unlock()). -Rust's lifetime rules are complex and different from all other existing languages. It is challenging for Rust programmers to infer where a variable's lifetime ends. As a result, it is not uncommon for programmers to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers' expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to double lock or lock in conflicting orders. +Rust's lifetime rules are complex and different from all other existing languages. It is challenging for Rust programmers to infer where a variable's lifetime ends. As a result, it is not uncommon for programmers to incorrectly identify the location where an implicit unlock is called. When a lock is held longer than programmers' expectation, the same lock may be acquired again or a different lock may be acquired before releasing the acquired lock, leading to a double-lock error or a lock-in-conflicting-orders error. In our previous work [1], we conducted an empirical study on real-world Rust concurrency bugs. We inspected GitHub commit logs for five Rust applications and five Rust libraries to collect previously fixed concurrency bugs. In total, we found 37 deadlocks due to the misunderstanding of where the implicit Unlock() is called, including 30 double locks and seven locks acquired in conflicting orders. These deadlocks constitute almost all lock-related concurrency bugs (37/38) in our collection. They are all from popular Rust software systems (e.g., Servo, Parity-Ethereum, TiKV, Redox) and have severely hurt the reliability of those systems before they were fixed. + A brief description of the project. -We propose to build an IDE tool for visualizing the lifetime scope of a user-selected variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting blocking operations or function calls leading to blocking operations. +We propose to build an IDE tool for visualizing the lifetime scope of a user-selected Rust variable. We believe our tool can help Rust programmers avoid deadlocks at the development stage. After writing a piece of code involving a mutex, a programmer can select the return value of a locking operation or the locking operation itself (when the return is not saved to a variable). Our tool will visualize the lifetime scope of the return value (i.e., the critical section). The programmer can then inspect whether the end of the critical section is expected. In addition, our tool will conduct deadlock detection for the selected critical section and provide detailed debugging information for identified bugs, such as highlighting blocking operations or function calls leading to blocking operations. How our tool will be integrated into Substrate/Polkadot? -Both Substrate and Polkadot are implemented in Rust. Previously, double locks or locks in conflicting orders were fixed in Substrate [2, 3]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [4, 5, 6]. We believe our tool can effectively prevent Substrate/Polkadot programmers from making similar mistakes and other types of mistakes our tool will reveal. +Both Substrate and Polkadot are implemented in Rust. Previously, double locks or locks in conflicting orders were fixed in Substrate [2, 3]. After applying our prototype, we identified four previously unknown double locks in Substrate or the dependent libraries of Substrate/Polkadot. We reported detected bugs. All of them were confirmed and fixed by developers [4, 5, 6]. We believe our tool will effectively prevent Substrate/Polkadot programmers from making similar mistakes and other types of mistakes our tool will reveal. Why are we interested in creating this project? We are interested in building the tool due to three reasons. First, our previous empirical study shows that deadlocks due to the misunderstanding of Rust's lifetime rules are common in Rust programs. Visualizing lifetime can avoid these bugs during the development stage, benefiting the whole Rust community. Second, the misunderstanding of Rust's lifetime rules can also cause memory bugs such as use-after-free and double free. Thus, the proposed tool has the potential to combat memory bugs. Third, the experience of building the proposed tool can inspire similar tools for other programming languages featuring lifetime (e.g., Kotlin). @@ -43,7 +44,7 @@ We are interested in building the tool due to three reasons. First, our previous ### Project Details What have we already done? -We have built a prototype of the proposed tool. Our prototype can visualize a selected variable and conduct double-lock detection. We published a demonstration paper at this year's CCS to describe the prototype. The paper can be found [here](https://songlh.github.io/paper/vr.pdf). We also recorded a video to explain the prototype, and the video can be found [here](https://youtu.be/L5F_XCOrJTQ). +We have built a prototype of the proposed tool. Our prototype can visualize a selected variable and conduct double-lock detection. We published a demonstration paper at CCS'2020 to describe the prototype. The paper can be found here: https://songlh.github.io/paper/vr.pdf. We also recorded a video to explain the prototype, and the video can be found here: https://youtu.be/L5F_XCOrJTQ. We applied the double-lock detection component to Substrate, Polkadot, and ink!. We found four previously unknown deadlocks. One is in Substrate. The other three are in the dependent libraries of Substrate or Polkadot. We reported all the detected bugs. All of them were fixed by developers based on our reporting. The information of the detected bugs is listed as follows: @@ -55,13 +56,16 @@ We applied the double-lock detection component to Substrate, Polkadot, and ink!. [PR-3] https://github.com/paritytech/parity-common/pull/396 What are we going to do? -We propose to extend the prototype along three directions: +We propose to extend the prototype along four directions: + +First, we will integrate our existing implementation of lifetime computation and deadlock detection to Rust language Server (RLS), so that our proposed technique can easily cooperate with different text editors. + +Second, we will detect more types of deadlock bugs. Specifically, we will add the detection of locks with conflicting orders and misuse of mutex and non-mutex synchronization primitives (e.g., channel, conditional variable). -First, we will add the bug detection functionality for more deadlock types. Specifically, we will add the detection of locks with conflicting orders and misuse of mutex and non-mutex synchronization primitives (e.g., channel, conditional variable). +Third, we will identify and visualize more blocking operations that can potentially lead to deadlocks in a selected critical section such as receiving from a channel and waiting on a conditional variable. -Second, we will identify and visualize more blocking operations that can potentially lead to deadlocks in a selected critical section such as receiving from a channel and waiting on a conditional variable. +Fourth, we will implement the visualization functionality by parsing the analysis results generated by RLS in a text editor (i.e., VS Code) and document our tool. -Third, we will integrate the above bug detection and visualization functionalities and document our tool. @@ -76,8 +80,8 @@ There is no existing project similar to ours. * Names of team members: Linhai Song, Yiying Zhang, and Ziyi Zhang ### Team Website -* [Linhai Song’s homepage](https://songlh.github.io/) -* [Yiying Zhang’s homepage](https://cseweb.ucsd.edu/~yiying/) +* [Linhai Song's homepage](https://songlh.github.io/) +* [Yiying Zhang's homepage](https://cseweb.ucsd.edu/~yiying/) ### Legal Structure @@ -114,7 +118,7 @@ Team member Yiying Zhang has conducted various systems research with papers publ ### Overview -We will build the proposed tool as a plugin of [VSCode](https://github.com/microsoft/vscode), which is an open-source IDE project. We will implement the proposed program analysis by analyzing Rust’s MIR. +We will integrate the proposed tool into RLS and demonstrate the virtualization functionality in [VSCode](https://github.com/microsoft/vscode), which is an open-source IDE project. We will implement the proposed program analysis by analyzing Rust's MIR. We divide the project into three milestones. We aim to finish the whole project in three months and achieve a milestone in each month. @@ -139,34 +143,35 @@ We divide the project into three milestones. We aim to finish the whole project | 4. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | -### Milestone 2 — Implement the visualization component +### Milestone 2 — Integrate the bug detection functionalities into RLS * **Estimated Duration:** 1 month | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to install and use the visualization component in VSCode. | -| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs to test whether channel operations are correctly identified, whether channel operations are correctly visualized, whether operations on conditional variables are correctly identified, and whether operations on conditional variables are correctly highlighted. | -| 1. | Channel Operation Identification Module | We will identify channel operations or function calls that may lead to channel operations by conducting inter-procedural analysis. | -| 2. | Channel Operation Highlighting Module | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified channel operations in the selected critical section. | -| 3. | Conditional Variable Operation Identification Module | We will identify operations on a conditional variable or function calls that may lead to operations on a conditional variable by conducting inter-procedural analysis. | -| 4. | Conditional Variable Operation Highlighting Module | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified operations on a conditional variable in the selected critical section. | -| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to install and use the changed RLS. | +| 0c. | Testing Guide | We will also use the 10 toy programs designed in the last milestone to test whether the bug detection capability is successfully integrated into RLS. | +| 1. | Extend Language Server Protocol (LSP) | We will extend LSP to contain the key information related to deadlocks (e.g., the start and the end of a critical section, blocking operations in a critical section).| +| 2. | Change RLS to emit MIR | We will change the build module of RLS to emit MIR for our bug detection functionalities. | +| 3. | Conduct bug detection in RLS | We will change the analysis crate of RLS to execute the code for bug detection and change the server module to send the detection results out. | +| 4. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | + +### Milestone 3 — Implement the visualization component -### Milestone 3 — Integrate the bug detection component with the visualization component * **Estimated Duration:** 1 month | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to use the tool. | -| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs containing different types of deadlocks to demonstrate the buggy blocking operations are correctly identified and highlighted. | -| 1. | Integrating the Visualization Component with the Bug Detection Component | We will integrate the bug detection component with the visualization component. | -| 2. | Tutorial Writing | We will write a tutorial and record a video to explain how to use our tool. | -| 3. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to install and use the visualization component in VSCode. | +| 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs to test whether channel operations are correctly identified, whether channel operations are correctly visualized, whether operations on conditional variables are correctly identified, and whether operations on conditional variables are correctly highlighted. | +| 1. | Parse the Extended LSP | We will implement a component to parse the extended LSP and get computed information, such as the scope of a critical section and identified block operations. | +| 2. | Highlight Blocking Operations | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified channel operations, conditional variable operations, and locking operations in the selected critical section. | +| 3. | Tutorial Writing | We will write a tutorial and record a video to explain how to use our tool. | +| 4. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. | From 9d0d223a53daf6b1662ab1fbb8063b12739254b5 Mon Sep 17 00:00:00 2001 From: Linhai Song Date: Thu, 4 Mar 2021 15:49:59 +0800 Subject: [PATCH 21/21] fix a typo --- grants/speculative/visualize_rust_lifetime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grants/speculative/visualize_rust_lifetime.md b/grants/speculative/visualize_rust_lifetime.md index 07aa7dac2..899ff6b6a 100644 --- a/grants/speculative/visualize_rust_lifetime.md +++ b/grants/speculative/visualize_rust_lifetime.md @@ -168,7 +168,7 @@ We divide the project into three milestones. We aim to finish the whole project | 0a. | License | Apache 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how to install and use the visualization component in VSCode. | | 0c. | Testing Guide | We will include unit tests to ensure the functionality and robustness of our code. We will also include 10 toy programs to test whether channel operations are correctly identified, whether channel operations are correctly visualized, whether operations on conditional variables are correctly identified, and whether operations on conditional variables are correctly highlighted. | -| 1. | Parse the Extended LSP | We will implement a component to parse the extended LSP and get computed information, such as the scope of a critical section and identified block operations. | +| 1. | Parse the Extended LSP | We will implement a component to parse the extended LSP and get computed information, such as the scope of a critical section and identified blocking operations. | | 2. | Highlight Blocking Operations | If a selected variable is the return of a locking operation, besides visualizing the critical section, we will also highlight identified channel operations, conditional variable operations, and locking operations in the selected critical section. | | 3. | Tutorial Writing | We will write a tutorial and record a video to explain how to use our tool. | | 4. | Docker | We will provide a dockerfile to demonstrate the full functionality of this component. |