Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

set up automated code reviews #4

Closed
derekbruening opened this issue Nov 27, 2014 · 1 comment
Closed

set up automated code reviews #4

derekbruening opened this issue Nov 27, 2014 · 1 comment
Labels
Migrated Priority-Critical Status-Fixed

Comments

@derekbruening
Copy link
Contributor

From [email protected] on February 12, 2009 11:02:16

we're going to use the commit-diff-to-svn approach.
this case covers adapting core/Makefile's "make diffsend" set of rules to
use the new approach.

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=4
@derekbruening
Copy link
Contributor Author

From [email protected] on February 13, 2009 13:45:03

basic "make review" is committed. new Issues will be opened for any future problems.

Status: Verified

This was referenced Nov 27, 2014
Closed
Closed
Closed
Closed
Closed
Closed
Open
Open
Closed
Open
Open
Open
Open
Closed
Open
Closed
Closed
Open
Closed
Closed
Closed
Closed
Open
Closed
This was referenced Nov 28, 2014
Closed
Open
Closed
Open
Open
Open
Closed
@groleo groleo mentioned this issue Dec 17, 2014
Closed
@zhaoqin zhaoqin mentioned this issue Mar 20, 2015
Open
@zhaoqin zhaoqin mentioned this issue Apr 9, 2015
Open
@derekbruening derekbruening mentioned this issue Apr 16, 2015
Closed
@zhaoqin zhaoqin mentioned this issue Jul 9, 2015
Open
@derekbruening derekbruening mentioned this issue Mar 15, 2017
Open
@Carrotman42 Carrotman42 mentioned this issue Sep 22, 2018
Open
@hgreving2304 hgreving2304 mentioned this issue Oct 22, 2018
Open
@Carrotman42 Carrotman42 mentioned this issue Jul 25, 2019
Open
@Desperado1985 Desperado1985 mentioned this issue Mar 24, 2020
Closed
@Desperado1985 Desperado1985 mentioned this issue May 1, 2020
Closed
@Desperado17 Desperado17 mentioned this issue May 1, 2020
Open
slackito added a commit to slackito/dynamorio that referenced this issue Jun 23, 2020
@slackito
Fix NULL pointer dereference.
32db607 
This dereference can happen with the following call stack:

    #0 0x564752dc571f in linkstub_fragment dynamorio/trunk/core/link.c:482:30
    DynamoRIO#1 0x564752dc5753 in set_last_exit dynamorio/trunk/core/link.c:581:31
    DynamoRIO#2 0x564752d4b234 in initialize_dynamo_context dynamorio/trunk/core/dynamo.c:1812:5
    DynamoRIO#3 0x564752d4848c in dynamo_thread_init dynamorio/trunk/core/dynamo.c:2310:5
    DynamoRIO#4 0x564752d461ed in dynamorio_app_init dynamorio/trunk/core/dynamo.c:636:9
    DynamoRIO#5 0x564752d4c11f in dr_app_setup dynamorio/trunk/core/dynamo.c:2754:11

because dcontext->link_field is only initialized by link_thread_init,
which is called further down dynamo_thread_init.
derekbruening pushed a commit that referenced this issue Jun 23, 2020
@slackito
Fix NULL pointer dereference. (#4333)
4b9776e 
Fixes an instance of a NULL pointer being accessed.
Although this is a "benign" dereference (it is only used to compute the address of a member of a struct and no actual memory access is attempted), this is still undefined behavior and it causes problems when using tools like UndefinedBehaviorSanitizer.

This dereference can happen with the following call stack:

    #0 0x564752dc571f in linkstub_fragment dynamorio/trunk/core/link.c:482:30
    #1 0x564752dc5753 in set_last_exit dynamorio/trunk/core/link.c:581:31
    #2 0x564752d4b234 in initialize_dynamo_context dynamorio/trunk/core/dynamo.c:1812:5
    #3 0x564752d4848c in dynamo_thread_init dynamorio/trunk/core/dynamo.c:2310:5
    #4 0x564752d461ed in dynamorio_app_init dynamorio/trunk/core/dynamo.c:636:9
    #5 0x564752d4c11f in dr_app_setup dynamorio/trunk/core/dynamo.c:2754:11

because dcontext->link_field is only initialized by link_thread_init,
which is called further down dynamo_thread_init.
@derekbruening derekbruening mentioned this issue Jan 28, 2021
Closed
@abudankov abudankov mentioned this issue Jul 21, 2021
Open
@MAXZVER MAXZVER mentioned this issue Nov 29, 2021
Open
@zenhumany zenhumany mentioned this issue Nov 30, 2021
Closed
@bete0 bete0 mentioned this issue Jul 31, 2023
Merged
@atharvabhanage12 atharvabhanage12 mentioned this issue Nov 1, 2023
Open
@akhileshkumar80 akhileshkumar80 mentioned this issue Mar 1, 2024
Closed
derekbruening added a commit that referenced this issue Jul 16, 2024
@derekbruening
i#6884: Add drmemtrace signal number marker
d32d876 
Adds a new drmemtrace marker holding the signal number which is
emitted after the kernel event marker.  It is not emitted at the
signal return point; only at the transfer to the handler.

Does not add a feature bit or increase the version as this marker is
considered optional and so no mechanism is provided for users to be
guaranteed that it is present.

Adds view tool support.

Adds a test that the marker is emitted in the burst_gencode test.
Output from the test's trace:
```
          52          32:     1616564 ifetch       2 byte(s) @ 0x00007f615935d023 0f 0b                ud2
          53          32:     1616564 <marker: kernel xfer from 0x7f615935d023 to handler>
          54          32:     1616564 <marker: signal #4>
          55          32:     1616564 <marker: timestamp 13365562571171519>
          56          32:     1616564 <marker: tid 1616564 on core 9>
          57          33:     1616564 ifetch       1 byte(s) @ 0x00005641b091170b 55                   push   %rbp
```

Fixes #6884
derekbruening added a commit that referenced this issue Jul 16, 2024
@derekbruening
i#6884: Add drmemtrace signal number marker (#6885)
1211505 
Adds a new drmemtrace marker holding the signal number which is emitted
after the kernel event marker. It is not emitted at the signal return
point; only at the transfer to the handler.

Does not add a feature bit or increase the version as this marker is
considered optional and so no mechanism is provided for users to be
guaranteed that it is present.

Adds view tool support.

Adds a test that the marker is emitted in the burst_gencode test. Output
from the test's trace:
```
          52          32:     1616564 ifetch       2 byte(s) @ 0x00007f615935d023 0f 0b                ud2
          53          32:     1616564 <marker: kernel xfer from 0x7f615935d023 to handler>
          54          32:     1616564 <marker: signal #4>
          55          32:     1616564 <marker: timestamp 13365562571171519>
          56          32:     1616564 <marker: tid 1616564 on core 9>
          57          33:     1616564 ifetch       1 byte(s) @ 0x00005641b091170b 55                   push   %rbp
```

Fixes #6884
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Migrated Priority-Critical Status-Fixed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@derekbruening