summaryrefslogtreecommitdiffstats
path: root/sigchainlib/sigchain.h
Commit message (Collapse)AuthorAgeFilesLines
* ART: Add support for special handlers in sigchainlibAndreas Gampe2015-05-311-0/+3
| | | | | | | | | | | | | | Add support for a special managed handler in sigchainlib that will be called as the first user handler. Use this support for native bridge v2. Extend test 115-native-bridge to test the functionality. Bug: 20217701 (cherry picked from commit 03c2cc89428914adf52229d6a3867eef6127911a) Change-Id: I78cc01fbdabe169154ff6b94c9f3ddb95b5c7448
* Add way to ensure we are at the front of the sigaction chainMathieu Chartier2014-10-161-0/+6
| | | | | | | | | | | | | | | | | | | Calling this after jni_on_load fixes the unity apps. This is not exactly correct since we may already have the following chain. Start up: Us -> debuggerd After app goes in front: App -> us -> debuggerd After we put ourself back at the front: Us -> app -> us -> app -> .... stack overflow. Bug: 17620677 Change-Id: I9183997e3d5ebd51c320b5d51425be5142e938f3 (cherry picked from commit 1f24296c7c8a6501ee2388c0d20b48f471b48660)
* Remove libsigchain from LD_PRELOADSDmitriy Ivanov2014-10-071-8/+4
| | | | | | | | | | | | Link sigchain.cc statically with dalvikvm, app_process, surfaceflinger, dex2oat, patchoat and objdump. Replace libsigchain.so with dummy implementaions to avoid situations when it is used incorrectly. Bug: 15345057 Bug: 15426766 Change-Id: If0b7f59a59824e30aa0c33dad76c7a44932180de
* Don't call dlsym from signal context in signal chainDave Allison2014-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | It is dangerous to call dlsym from within a signal context since it takes a lock and can lead to a mutex reentry attempt if timing is bad. This change adds an initialization function to the signal chain that calls dlsym for sigaction and sigprocmask from outside the signal context (from Runtime::Init()). The results are cached in a static variable and used from within the signal context if necessary. However, tests don't necessarily call Runtime::Init() so we also need to deal with the case where the signal chain is not initialized and perform a lazy initialization from inside sigaction or sigprocmask. This is always outside a signal context since we have not initialized the runtime. Bug: 17498571 Change-Id: I59eebfc67cc91c6f1d781a73e5d432ca5269ee48
* Remove object_utils.h.Ian Rogers2014-07-161-0/+3
| | | | | | | | | Break into object_lock, field_helper and method_helper. Clean up header files following this. Also tidy some of the Handle code in response to compiler errors when resolving the changes in this CL. Change-Id: I73e63015a0f02a754d0866bfaf58208aebcaa295
* Make use of sigchainlib for signal chaining for implicit checksDave Allison2014-05-291-0/+29
This adds a preload library that overrides sigaction and sigprocmask to implement signal chaining. Signal chaining allows us to chain any signal so that the ART runtime receives it before any signal handler registered in native code by an application. If the ART signal handler doesn't want it, it will pass it on to the user's handler. ART uses signals for null pointer checks, stack overflow checks and suspend points. Also adds an OAT test to test this in isolation. Change-Id: I9545f9f7343774c091410eb810504d9855fd399f