在Eclipse中连接的现场设备步进时不正确开源观点 [英] Incorrect java open source view when stepping in Eclipse with live device connected
问题描述
我试图调试<一个href=\"http://stackoverflow.com/questions/27862830/samsung-g5-nullpointerexception-on-setvisibility\">this Android应用程序的问题，似乎只出现在三星G5 v4.4.4设备。要尝试跟踪NullPointerException异常的来源，这将有助于加强通过Java开源$ C $ C，其中的NPE发出信号。问题是，当我们使用仿真器三星G5 v4.4.4，应用程序没有抛出NPE ，我们能够通过行通过开源线步骤。然而，当我们连接了三星G5设备到Eclipse，并尝试逐步执行code，当它进入开源的显示源$ C $ C，但它显然是不正确。我们知道这一点，例如，因为它似乎在开放源代码的注释行通过一步。已经审查了与源$ C $ C没有找到许多文章，但在我们的例子中，我们似乎有正确的源$ C $ C，在模拟器调试模式至少在。
Am trying to debug this Android app issue that seems to occur only on Samsung G5 v4.4.4 device. To try to trace the source of the NullPointerException, it would help to step through the java open source code where the NPE is signaled. The problem is that when we use an emulator for Samsung G5 v4.4.4, the app does not throw an NPE and we are able to step through the open source line by line. However, when we connect the Samsung G5 device to Eclipse, and try to step through the code, when it enters java open source the source code is displayed but it is clearly incorrect. We know this for example because it appears to "step through" comment lines in the open source. Have reviewed many articles related to source code not found, but in our case we do seem to have correct source code, at least when in emulator debug mode.
如果任何人都可以在这个特定的调试问题提供指导，也许它可以帮助我们（仅适用于三星G5）隔离我们的应用程序问题的原因。所有的建议表示欢迎。
If anyone can provide guidance on this specific debugging issue, perhaps it can help us isolate the cause of our app issue (on Samsung G5 only). All suggestions welcome.
- 开发平台的Mac OSX 10.9.5。
- 的Eclipse 23.0.2.1259578。
- Android SDK工具24.0.2
- Android SDK中平台的工具，启21
- Android SDK中内置的工具启21.1.2（也启20和19.1版本安装）
- 各种Android的API安装，包括API 21，20，19M，18，17，16，14
- 三星G5（冲刺）软件版本G900PVPU1ANK4，硬件版本G900P.04。 Android的4.4.4
要做出一点点进步，我通过三星（其中source code的观点是不正确大部分），然后仿真器（其中source观点是正确的）加强。无论是所谓的Android 4.4.4，但我们认为三星已经从AOSP修改。通过比较code的线条和一些可变的状态，我们可以看什么三星在做什么，即使源$ C $ C的观点是不正确。我不希望任何人这种技术，但它起到了一定作用，帮助我们了解我们的三星G5应用程序检测到的错误一点并报告<一href=\"http://stackoverflow.com/questions/27862830/samsung-g5-nullpointerexception-on-setvisibility\">this SO质疑。
To make a bit of progress, I stepped through Samsung (where source code view is mostly incorrect) and then Emulator (where source view is correct). Both are supposedly Android 4.4.4, but we assume that Samsung has modified from the AOSP. By comparing the lines of code and some variable states, we can "watch" what the Samsung is doing, even though the source code view is incorrect. I would not wish this technique on anyone, but it served a purpose to help us learn a little about the error observed from our app on Samsung G5 and reported on this SO question.
推荐答案
在这种情况下，preferred的方法可能是找到特定厂商的Android的Java源文件，并包括Eclipse来对它的引用。然而，供应商不使这个容易，我们始终没能找到它。
The preferred approach in this case is probably to find the vendor-specific Android java source file and include a reference to it for Eclipse. However, the vendors don't make this easy, and we were never able to find it.
通过细心和耐心，以及一点点运气，你可以，只要它具有与其他程序足够的共性跟踪程序。在我们的例子中，三星v4.4.4可以与Eclipse v4.4.2进行比较和相关性，以确定下来code的引起异常的行。首先获得code面积的一个基本的了解（在您的应用程序并在相关的开放源代码），是有关的问题。然后，你将开始建立地图什么是应该发生的（没有错误）与什么是不与故障设备发生。这是基本过程：
1.一步结果得到一个记事本记录的一步。我们不得不为设备行数一栏，然后在模拟器行号，则模块/方法的名称，然后指令。
2.在你知道会导致异常的应用软件的线code的设置一个断点。
3.启动模拟器并运行调试到断点。
4.使用单步执行记录由堆栈跟踪报道的每一行。注意模块/方法，当它改变时，如果code线似乎相关或有趣，也记录下来。
5.继续录制你的记事本的执行每一行此信息，直到你知道你已经通过的地步设备将抛出异常的进展。
6.停止执行，（也许是重新启动Eclipse），连接设备，并运行调试到断点。
7.在某些情况下，正在显示的源将似乎是执行注释行，或将跳进一个方法的中间，而不是它的入口点。您正在寻找线索，帮助您确定该设备可能会在源$ C $ C来操作。一个证据是行数从一步到下一增加。显然，如果行号被一个，它的一个单行指令增大。如果跳跃由两个或几个，它可能是一个如果。等等。信息的其他关键部分是调试变量。例如，如果code在著名的好的源行 A = 10; ，那么你有时可以查看变量 A 该行code之前（可能是空为例），然后该行code之后。如果你对自己的来源映射正确的，那么你会看到 A 更改为10
With care and patience, and a bit of luck, one can trace a program as long as it has enough commonality with another program. In our case, the Samsung v4.4.4 could be compared with the Eclipse v4.4.2 and correlated to determine down to the line of code causing the exception. First get a basic understanding of the area of code (in your app and across the relevant open source) that is relevant to the issue. Then you will begin to build a map of what "should" happen (no error) versus what "does" happen with the failure device. This was the basic process:
1. Get a notepad to record step by step results. We had a column for "device line number", then "emulator line number", then module/method name, then instruction.
2. Set a breakpoint on a line of code in the app software that you know will lead to the exception.
3. Start the emulator and run debug to the breakpoint.
4. Use Step Into to record each line reported by the stack trace. Note the module/method when it changes, and if the line of code seems relevant or interesting, record it also.
5. Continue recording this information on your notepad for every line executed until you know that you have progressed through the point where the device will throw the exception.
6. Stop the execution, (perhaps restart Eclipse), connect the device, and run debug to the breakpoint.
7. In some cases, the source being displayed will seem to be "executing" comment lines, or will jump into the middle of a method rather than to its entry point. You are looking for clues that help you determine where the device might be operating in the source code. One piece of evidence is the number of lines increase from one step to the next. Obviously, if the line number increases by one, its a one-line instruction. If it jumps by two or a few, its likely an if. And so on. The other key piece of information is the debug Variables. For example, if a line of code in the known "good" source is a = 10; then you can sometimes view the variable a before that line of code (it might be null for example), and then after that line of code. If you are correct about your mapping of the source, then you'll see the value of a change to 10.
这仅适用于code是相对一致的。我们看到，例如，4.4.4三星源将是关闭在某些情况下，由50或者甚至超过100个线，虽然厂商已插入的新方法。但我们能够通过我们可以查看源追踪它。不管是值得花时间或没有，就很难说了。最后，我们实现了空指针的东西是我们不能战胜的，我们选择了一个完全不同的方法来实现这一目标。
This only works for code that is relatively the same. We saw for example, the 4.4.4 Samsung source would be off in some cases by 50 or even 100+ lines, as though the vendor had inserted a new method. But we were able to trace it through the source we could view. Whether it was worth the time or not, is hard to say. In the end we realized the null pointer was something we couldn't conquer, and we chose a completely different approach to achieve the goal.
这篇关于在Eclipse中连接的现场设备步进时不正确开源观点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
