Skip to content

Conversation

@sergeuz
Copy link
Member

@sergeuz sergeuz commented Apr 10, 2016

Fixes #927


Doneness:

  • Contributor has signed CLA
  • Problem and Solution clearly stated
  • Code peer reviewed
  • API tests compiled
  • Run unit/integration/application tests on device
  • Add documentation
  • Add to CHANGELOG.md after merging (add links to docs and issues)

@m-mcgowan
Copy link
Contributor

how about adding some tests for this? registering thousands of successive handlers to the same interrupt should be sufficient to show that there is no memory leak and that deleting the old handlers works without causing a fault. We also have System.freeMemory() which could be used to validate that memory isn't being excessively leaked.

@sergeuz
Copy link
Member Author

sergeuz commented Apr 12, 2016

Added slightly less involved test case that I believe has similar coverage

@m-mcgowan m-mcgowan self-assigned this Apr 23, 2016
@m-mcgowan m-mcgowan merged commit 31f11b6 into develop Apr 27, 2016
@m-mcgowan
Copy link
Contributor

m-mcgowan commented Apr 27, 2016

  • Tested on the Photon.
  • Tested on the Core

Made the tests compile on the core by commenting out GPIO, PWM and Servo tests, which are unrelated. I think we will split the no_fixture tests into Peripheral tests and System tests on the core via a conditional define. so we can continue to compile and run the tests on the core.

@technobly technobly deleted the feature/interrupt_handler_leak branch October 27, 2016 17:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants