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

Something to watch out for: using addresses as search keys can cause an ABA address-recycling bug #11

Closed
henricasanova opened this issue Dec 5, 2017 · 1 comment
Closed

Something to watch out for: using addresses as search keys can cause an ABA address-recycling bug #11

henricasanova opened this issue Dec 5, 2017 · 1 comment
Labels
warning

Comments

@henricasanova
Copy link
Contributor

In many parts of the code we use addresses of objects to search for their presence in lists. This is susceptible to the ABA address-recycling bug. For instance:

  • I allocate a StandardJob, which has adress 0xAAAA
  • I start an Alarm to let me know that that job has expired
  • The job completes normally well ahead of the expiration
  • I allocate ANOTHER StandardJob, which ALSO has address 0xAAAA because the heap allocator reuses the same location
  • That other job runs, and at some point I get the "job expired" message from the Alarm for job 0xAAAA

In this way, I am mistaking an "old message that I should ignore" for a "oh no, a job has expired" message.

The way to fix this: create a unique sequence number for each StandardJob (static variable inside the constructor that gets incremented). Then, before sending the message, the Alarm could, for instance, check that the sequence number of the job at address 0xAAAAA has not changed. Or, the message could be sent regardless, and the recipient of the message would then do the check. In essence, the check is: "yes, there is a job at that address you're telling me about, but let me checked if it's really the job you mean".
@henricasanova henricasanova removed the bug label Feb 1, 2018
@henricasanova henricasanova changed the title Potential bug: using addresses as search keys and the ABA address-recycling bug Something to watch out for: using addresses as search keys can cause an ABA address-recycling bug Feb 1, 2018
@henricasanova
Copy link
Contributor Author

moved to wiki

julien-monniot pushed a commit to julien-monniot/wrench that referenced this issue Feb 7, 2023
# This is a combination of 13 commits.
0580e62 
# This is the 1st commit message:

Adding skeleton for a CompoundStorageService (heavily inspired by SimpleStorageService)

# This is the commit message wrench-project#2:

CompoundStorageService starts (working service state, even though it doesn't do anything yet)

# This is the commit message wrench-project#3:

CompoundStorageService : adding method to get all internal services ; FileLocation : adding two methodes to update storage service and mount point of an existing FileLocation ; BareMetalCompoundService: adding a very simple (and dirty) code block to automatically replace a CompoundStorageService in a Read or Write file Action with its first (or only) internal concrete storage service ; BatchComputeService: just tinkering with comments in order to find an appropriate place to put the same kind of code block as in BareMetalComputeService

# This is the commit message wrench-project#4:

Fixing CompoundStorageService after last merge from master: manually adding a LogicalFilesystem on /dev/null, updating the use od StorageService constructor and adding proper messagepayloadsize and property values init.

# This is the commit message wrench-project#5:

New scheduler (copy of ConservativeBackfilling, but storage-aware)

# This is the commit message wrench-project#6:

Functional test added for CompoundStorageService. Also overriding some parent methods in CSS for coherency, and putting in place a few safeguards. Test is still incomplete (but passing at the moment)

# This is the commit message wrench-project#7:

Updating CompoundStorageService so that it can safely discard Read/Write/Delete/Lookup/Copy message requests (it answers with a failure cause stating that the feature in not available) ; updated test accordingly

# This is the commit message wrench-project#8:

Fixing a small bug in the new test setup

# This is the commit message wrench-project#9:

Cleaning up batch scheduler for storage, adding some logging in CompoundStorageService and cleaning up functionnal test

# This is the commit message wrench-project#10:

Minor clean-up and comments

# This is the commit message wrench-project#11:

First (probably still broken) implementation of message transfer inside the CSS -> tested for FileCopy and FileRead, and it seems to work..

# This is the commit message wrench-project#12:

Minor fix to the Storage selection callback in CSS

# This is the commit message wrench-project#13:

Working on tests for message transfers in CSS (currently there's a crash by action deadlock in the test simulation, but several fixes already implemented)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
warning
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rafaelfsilva @henricasanova