Default to the debug key if --sign provided without -s/-a/-p #3
Comments
facebook-github-bot
pushed a commit
that referenced
this issue
Mar 6, 2018
Summary: the OatDexFileRecord appears to be v131 only but we are still attempting to write it at 8.0 v124 on an mac this results in a segfault when we attempt to write: * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeefc00000) ... frame #3: 0x0000000100000851 oatmeal`FileHandle::fwrite_impl(this=0x00007ffeefbfcfb8, p=0x00007ffeefbfd071, size=1, count=2811670808) at OatmealUtil.cpp:16 ... on the device we get a message in stderr with native/redex/tools/oatmeal/OatmealUtil.cpp:60 CHECK(fh.fwrite(buf.ptr, sizeof(char), buf.len) == buf.len) failed. but the binary doesnt seem to crash even though there is an assert there. Reviewed By: maxmg22 Differential Revision: D7158457 fbshipit-source-id: e4f52cb4184ec519f30a4f11948e4633ad152c9b
diegoflassa
pushed a commit
to diegoflassa/redex
that referenced
this issue
Apr 16, 2018
Summary: the OatDexFileRecord appears to be v131 only but we are still attempting to write it at 8.0 v124 on an mac this results in a segfault when we attempt to write: * thread facebook#1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeefc00000) ... frame facebook#3: 0x0000000100000851 oatmeal`FileHandle::fwrite_impl(this=0x00007ffeefbfcfb8, p=0x00007ffeefbfd071, size=1, count=2811670808) at OatmealUtil.cpp:16 ... on the device we get a message in stderr with native/redex/tools/oatmeal/OatmealUtil.cpp:60 CHECK(fh.fwrite(buf.ptr, sizeof(char), buf.len) == buf.len) failed. but the binary doesnt seem to crash even though there is an assert there. Reviewed By: maxmg22 Differential Revision: D7158457 fbshipit-source-id: e4f52cb4184ec519f30a4f11948e4633ad152c9b
diegoflassa
pushed a commit
to diegoflassa/redex
that referenced
this issue
Apr 19, 2018
Summary: the OatDexFileRecord appears to be v131 only but we are still attempting to write it at 8.0 v124 on an mac this results in a segfault when we attempt to write: * thread facebook#1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x7ffeefc00000) ... frame facebook#3: 0x0000000100000851 oatmeal`FileHandle::fwrite_impl(this=0x00007ffeefbfcfb8, p=0x00007ffeefbfd071, size=1, count=2811670808) at OatmealUtil.cpp:16 ... on the device we get a message in stderr with native/redex/tools/oatmeal/OatmealUtil.cpp:60 CHECK(fh.fwrite(buf.ptr, sizeof(char), buf.len) == buf.len) failed. but the binary doesnt seem to crash even though there is an assert there. Reviewed By: maxmg22 Differential Revision: D7158457 fbshipit-source-id: e4f52cb4184ec519f30a4f11948e4633ad152c9b
facebook-github-bot
pushed a commit
that referenced
this issue
Oct 15, 2019
Summary: Report: fbandroid/native/redex/libresource/VectorImpl.cpp:507:22: runtime error: null pointer passed as argument 2, which is declared to never be null fbcode/third-party-buck/platform007/build/glibc/include/string.h:43:28: note: nonnull attribute specified here Stack trace: ``` #0 android::VectorImpl::_do_copy (this=<optimized out>, dest=0x7fffd140c818, from=0x0, num=0) at fbandroid/native/redex/libresource/VectorImpl.cpp:507 #1 android::VectorImpl::setCapacity (this=0x7fffffff5ac0, new_capacity=25420576) at fbandroid/native/redex/libresource/VectorImpl.cpp:341 #2 0x0000000001f34f4a in android::Vector<char>::setCapacity (this=<optimized out>, size=17592186039131) at buck-out/gen/fbandroid/native/redex/libresource#header-mode-symlink-tree-with-header-map,headers/utils/Vector.h:85 #3 android::Vector<char>::reserve (this=<optimized out>, n=17592186039131) at buck-out/gen/fbandroid/native/redex/libresource#header-mode-symlink-tree-with-header-map,headers/utils/Vector.h:196 #4 android::ResTable::serialize (this=0x7fffffff66b0, cVec=..., resTableIndex=<optimized out>) at fbandroid/native/redex/libresource/ResourceTypes.cpp:4006 #5 0x0000000001e049eb in ResourcesArscFile::serialize (this=0x7fffffff66b0) at fbandroid/native/redex/libredex/RedexResources.cpp:1262 #6 0x00000000014ad94d in OptimizeResourcesPass::run_pass (this=0x24d25e0 <_ZL6s_pass>, stores=..., conf=..., mgr=...) at fbandroid/native/redex/facebook/opt/optimize_resources/OptimizeResources.cpp:630 #7 0x0000000001c6b2a9 in PassManager::run_passes (this=0x7fffffffb660, stores=..., conf=...) at fbandroid/native/redex/libredex/PassManager.cpp:258 #8 0x0000000000d2bb3a in main (argc=-25816, argv=0x7fffffffaf48) at fbandroid/native/redex/tools/redex-all/main.cpp:1122 ``` Reviewed By: int3 Differential Revision: D17889740 fbshipit-source-id: 360c1e7bd341a09f3537b9115cd2967d98b0c36c
facebook-github-bot
pushed a commit
that referenced
this issue
Aug 23, 2022
Summary: This diff introduces two main changes: ### Update Graph interface Currently, `predecessors` and `successors` in Graph trait returns `&[Self::EdgeId]`, this would be fairly efficient for Graph implementations that can return a slice. But I realized that in many cases, the Graph implementations may only be able to return an iterator (e.g., using petgraph). To make the interface more flexible, I decide to update it. There are three options for the new return type: ``` // 1. A iterator trait object (lazily evaluated, dynamic dispatch). fn predecessors(&self, n: Self::NodeId) -> Box<dyn Iterator<Item = Self::EdgeId> + '_>; // 2. Vector (heap alloc). fn predecessors(&self, n: Self::NodeId) -> Vec<Self::EdgeId>; // 3. SmallVec is similar to LLVM SmallVector, which can hold data in stack if its size is smaller than S. fn predecessors(&self, n: Self::NodeId) -> SmallVec<[Self::EdgeId; S]>; ``` With some benchmarking using different numbers of successors (etc.,1, 2, 4, 6, 8, 10), it turns out that the option #1 and #2 has similar performance, while option #3 is always slightly better than the other two. So I decided to adopt it. This will introduce a new dependency to our library but it's small. (later I can put this kind of benchmarking code in a separate bench folder.) ### Add a new trait for getting successor nodes In WPO, we need an interface to query the successor nodes of a given node. Previously I used a closure for it (while the C++ version uses std::function). After discussing with yuxuanchen1997, we think it's better to make this a separate trait to achieve this, so we add `SuccessorNodes` (The type that implements Graph trait can also implement Fn trait, but it's not recommended in Rust). In most cases, the same type can implement both. But they can also be separate types. In addition, this diff adds a naive graph implementation for testing. In this diff we only use it to test the `get_succ_nodes` interface. Reviewed By: yuxuanchen1997 Differential Revision: D38846203 fbshipit-source-id: 7951b83a7df6817b3796c1a4e40d85e08b4c2c12
facebook-github-bot
pushed a commit
that referenced
this issue
Aug 23, 2022
Summary: This diff introduces two main changes: ### Update Graph interface Currently, `predecessors` and `successors` in Graph trait returns `&[Self::EdgeId]`, this would be fairly efficient for Graph implementations that can return a slice. But I realized that in many cases, the Graph implementations may only be able to return an iterator (e.g., using petgraph). To make the interface more flexible, I decide to update it. There are three options for the new return type: ``` // 1. A iterator trait object (lazily evaluated, dynamic dispatch). fn predecessors(&self, n: Self::NodeId) -> Box<dyn Iterator<Item = Self::EdgeId> + '_>; // 2. Vector (heap alloc). fn predecessors(&self, n: Self::NodeId) -> Vec<Self::EdgeId>; // 3. SmallVec is similar to LLVM SmallVector, which can hold data in stack if its size is smaller than S. fn predecessors(&self, n: Self::NodeId) -> SmallVec<[Self::EdgeId; S]>; ``` With some benchmarking using different numbers of successors (etc.,1, 2, 4, 6, 8, 10), it turns out that the option #1 and #2 has similar performance, while option #3 is always slightly better than the other two. So I decided to adopt it. This will introduce a new dependency to our library but it's small. (later I can put this kind of benchmarking code in a separate bench folder.) ### Add a new trait for getting successor nodes In WPO, we need an interface to query the successor nodes of a given node. Previously I used a closure for it (while the C++ version uses std::function). After discussing with yuxuanchen1997, we think it's better to make this a separate trait to achieve this, so we add `SuccessorNodes` (The type that implements Graph trait can also implement Fn trait, but it's not recommended in Rust). In most cases, the same type can implement both. But they can also be separate types. In addition, this diff adds a naive graph implementation for testing. In this diff we only use it to test the `get_succ_nodes` interface. Reviewed By: yuxuanchen1997 Differential Revision: D38846203 fbshipit-source-id: 7951b83a7df6817b3796c1a4e40d85e08b4c2c12
facebook-github-bot
pushed a commit
that referenced
this issue
May 4, 2023
Summary: # Background When merging classes together, we have to also merge methods together to preserve the semantics of the program. When doing that we don't always clean up all the leftovers. That can cause the method count to go up immediately after a Class Merging pass, even though overall the merging transformation reduces class/method/field counts. The existing logic cleans up the merged methods at various places: 1. When merge ctors, we create a dispatch, force inline all entries in the dispatch, and we remove the original ctors after inlining. 2. When merging non-ctors and non-virtuals, we don't need to form a dispatch. We first dedup them and remove the ones replaced by the dedup process. 3. When merge true-virtuals, we form a dispatch. But right now we don't force inline each entries. That's where we leave a large number of methods to be clean up by the subsequent passes like Inlining or RMU. 4. Lastly, we purge merged classes with no dmethods left on the class. # What's in this change We need to clean up what's left by #3 above. Therefore, we force inline of the entries in a virtual dispatch we formed. After that, we only relocate the ones failed to be inlined to the merger class. Inlined entries remain on the merged class. They are then expected to be purged in #4 above. Reviewed By: ssj933 Differential Revision: D45417489 fbshipit-source-id: 7574a91d560dd71f53b7db67a6eb79e972e8ee02
facebook-github-bot
pushed a commit
that referenced
this issue
Jun 11, 2024
…ces class references Summary: Added a function to check for the META-INF/services directory in the root and as a submodule, and adding each file in said directory as an interface name, as well as the lines of each file as a class name. Then, making them all as REFLECTION. Reviewed By: wsanville Differential Revision: D58306108 fbshipit-source-id: f1e8d7eb8e5153622845fe445c3a98259399fbe4
facebook-github-bot
pushed a commit
that referenced
this issue
Feb 14, 2025
Summary: ## Context We add or patch missing annotations onto Kotlin synthesized method/fields to simplify the logic of the bytecode checker. Recently, after a round of refactoring in the `TypedefAnnoPatcher`, the patcher became nondeterministic. Here is an example [run](https://www.internalfb.com/chronos/job_instance/atn/1125914145183065/simple-logs) of our nondeterminism detector job. ``` Delta in TypedefAnnoCheckerPass#1 (#3) patched fields and methods: 137/136 signature~hash~: 4234545858429224/1792005371185171 ``` Thanks for the idea from Sushan, it seems like the way we [patch](https://www.internalfb.com/code/fbsource/[7bdd4ba579658dbf246abe528fb4b115228c5acd]/fbandroid/native/redex/opt/typedef-anno-checker/TypedefAnnoPatcher.cpp?lines=175%2C408%2C617%2C621%2C774%2C826%2C890) DexMethod/Field is not thread safe. It's only safe when it's single threaded. ## Solution The solution is to add lock before we go ahead and try to patch a DexMethod/Field. **Note** the code structure can be improved. But maybe in another diff. Reviewed By: ssj933 Differential Revision: D69626185 fbshipit-source-id: 0ce910a9262de5ba1bf7729d1968787d568924ba
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's nice to be able to sign with the debug key for, y'know, debugging, without specifying
-s $HOME/.android/debug.keystore -a androiddebugkey -p android. We should just try defaulting to those parameters.The text was updated successfully, but these errors were encountered: