1、JAVA问题定位技术 -常用的手段和工具,Page 2,议题,Page 3,线程堆栈 如何输出线程堆栈,Windows：在运行java的控制台上按ctrl+break组合键 Unix： 保留启动java的控制台，使用kill -3 ,堆栈的作用：线程死锁分析辅助CPU过高分析线程资源不足分析性能瓶颈分析关键线程异常退出,启动时进行重定向是一个不错的习惯： run.sh start.log 2&1,Page 4,线程堆栈如何解读线程堆栈？,wait() 会释放监视锁 sleep() 与锁操作无关,继续保持监视锁,当一个线程占有一个锁的时候，会打印- locked 当该线程正在等待别的线程释放该锁
2、，就会打印: waiting to lock 如果代码中有wait()调用的话，首先是locked,然后又会打印 - waiting on ,Wait也sleep的重大区别,Page 5,“http-0.0.0.0-27443-Processor4“ daemon prio=5 tid=0x599a7520 nid=0x1858 in Object.wait() 5c9ef0005c9efd88at java.lang.Object.wait(Native Method)- waiting on (a org.apache.tomcat.util.threads.ThreadPool$Cont
3、rolRunnable)at java.lang.Object.wait(Object.java:429)at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:655)- locked (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)at java.lang.Thread.run(Thread.java:534),线程堆栈如何解读线程堆栈？,表示该线程锁柱了该锁,表示正在线程正停在该对象的wait上面。 同时wai
4、t会自动释放该锁,Page 6,“smpp02:Sender-108“ daemon prio=5 tid=0x59a751a0 nid=0x13fc waiting for monitor entry 6066f0006066fd88at org.apache.log4j.Category.callAppenders(Category.java:185)- waiting to lock (a org.apache.log4j.spi.RootCategory)at org.apache.log4j.Category.forcedLog(Category.java:372)at org.ap
5、ache.log4j.Category.log(Category.java:864)at mons.logging.impl.Log4JLogger.debug(Log4JLogger.java:137)at m.base.server.AbstractHandler.send(AbstractHandler.java:407)at com.huawei.tellin.usr.uc.sendmessage.UCSMPPTransaction.send(UCSMPPTransaction.java:102)at com.huawei.tellin.usr.uc.sendmessage.UCSer
6、verProxy.synSend(UCServerProxy.java:134)at m.base.proxy.SendWorker.run(AbstractProxy.java:666)at com.huawei.uniportal.utilities.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)at java.lang.Thread.run(Thread.java:534),waiting to lock 表示该锁已经被别的线程使用，正在等待该锁被释放,线程堆栈如何解读线程堆栈？,Page 7,线程堆栈线程死锁分
7、析,Found one Java-level deadlock: = “thread1“:waiting to lock monitor 0x009fccb4 (object 0x10032710, a java.lang.Object),which is held by “thread1“ “thread1“:waiting to lock monitor 0x009fcc94 (object 0x10032718, a java.lang.Object),which is held by “thread1“Java stack information for the threads lis
8、ted above: = “thread1“:at DeadLockTest.run(DeadLockTest.java:44)- waiting to lock (a java.lang.Object)- locked (a java.lang.Object)at java.lang.Thread.run(Unknown Source) “thread1“:at DeadLockTest.run(DeadLockTest.java:24)- waiting to lock (a java.lang.Object)- locked (a java.lang.Object)at java.lan
9、g.Thread.run(Unknown Source),虚拟机已经告诉我哪里有死锁了，真不错,0x10032710 和 0x10032718 都在 等待对方释放，双方都被饿死,Page 8,线程堆栈用户代码导致CPU过高/热点线程分析,首先可以通过kill -3 pid(unix下) 或 +( windows下) 获取一个堆栈信息， 几分钟之后再获取一个，通过两个堆栈信息对比，将一直在忙的线程找出来。 通过分析对应的代码，确认不正常的线程。第一步：通过kill -3 java_pid 获取当前堆栈信息。 第二步：等待一段时间后。再获取一下当前堆栈信息。,Page 9,线程堆栈用户代码导致CP
10、U过高/热点线程分析,第三步：预处理前两个获取的堆栈信息，去掉处于sleeping或waiting的状态的线程。 例如如下线程处于wait或者sleep状态， 这种线程是不消耗CPU的，因此这些线程可以直接忽略掉，重点关注其它线程：,“EventManager-Worker-1“ daemon prio=8 tid=0x00c3ea58 nid=0x14a in Object.wait() 935ff000935ffc28 at java.lang.Object.wait(Native Method) /该线程已挂起，忽略掉 - waiting on (a org.exolab.core.ut
11、il.FifoQueue) at java.lang.Object.wait(Object.java:429),第五步：对比预处理后的1，2堆栈信息，找出处于busy状态的线程，该类线程可能是导致cpu高占用率的可疑线程。 例如：(下面的是在第一个堆栈信息中找到的处于active 活跃状态的线程)“http-80-Processor6“ daemon prio=5 tid=0x013ea770 nid=0x143 runnable 92eff00092f019c0 at com.huawei.u_mon.licmgr.LicenseIntf.nativeCheckLicense(Native
12、Method) at com.huawei.u_mon.licmgr.LicenseIntf.checkLicense(LicenseIntf.java:168) at com.huawei.u_sys.meetingone.sysmgr.ejb.LicRelateBean.updateLic(LicRelateBean.java:80),Page 10,线程堆栈用户代码导致CPU过高/热点线程分析,同一个线程在第二个堆栈信息中仍处于活跃状态。 “http-80-Processor6“ daemon prio=5 tid=0x013ea770 nid=0x143 runnable 92eff0
13、0092f019c0 at com.huawei.u_mon.licmgr.LicenseIntf.nativeCheckLicense(Native Method) at com.huawei.u_mon.licmgr.LicenseIntf.checkLicense(LicenseIntf.java:168) at com.huawei.u_sys.meetingone.sysmgr.ejb.LicRelateBean.updateLic(LicRelateBean.java:80),两次打印堆栈该线程一直在运行，说明该线程已运行了5分钟，请在代码中检查该线程是否属于长时间运行线程？如果属
14、于暂态线程，如此长时间运行说明可能有死循环等导致的CPU过高。,Page 11,线程堆栈线程资源不足分析,aused by: javax.transaction.TransactionRolledbackException: unable to create new native thread; nested exception is: java.lang.OutOfMemoryError: unable to create new native threadat org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTx
15、Interceptor.java:214)at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:148)at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:111)at org.jboss.ejb.plugins.LogInterce
16、ptor.invoke(LogInterceptor.java:191)at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.jav,Caused by: java.lang.OutOfMemoryError: unable to create new native threadat java.lang.Thread.start(Native Method)at .www.http.KeepAliveCache$1.run(KeepAliveCache.java:8
17、9)at java.security.AccessController.doPrivileged(Native Method)at .www.http.KeepAliveCache.put(KeepAliveCache.java:75)at .www.http.HttpClient.putInKeepAliveCache(HttpClient.java:382)at .www.http.HttpClient.finished(HttpClient.java:370),线程资源属于数量受限资源，一般一个Java进程中的线程数量不要过多， 如果太多虚拟机会拒绝创建。 可以通过打印线程堆栈，检查线程
18、的数量， 确认问题。如果确实属于线程数量过多，请更改线程模型设计,Page 12,性能瓶颈分析,什么叫高性能？-不同的场合有不同的指标。有的场合高性能意味着用户速度体验，如界面操作。- 适合使用OptimizeIt分析 还有的场合，高吞吐量意味着高性能，如短信。 - 适合使用堆栈分析 还有的场合是二者的结合，如IP电话- 适合使用堆栈分析,Page 13,性能瓶颈分析 Java应用的常见性能陷阱,不良的架构 不恰当的线程同步 资源的不恰当使用导致的资源竞争 不恰当的虚拟机运行参数 缓慢的磁盘/网络 IO 内存泄漏过分相信Java的自动垃圾回收机制,Page 14,性能瓶颈分析性能设计和调优的原
19、则,80-20原则: 20%的代码消耗了80%的资源，20%的代码执行消耗了80%的时间. 当前的性能瓶颈永远只有一处 只有解决了当前这一处性能瓶颈，你才知道下一个性能瓶颈在哪里性能瓶颈是动态的，低负载时不是瓶 颈 的地 方，在高负载时却可能成为瓶颈性能优化是一个持续的过程折中的艺术：在性能和灵活性之间寻找平衡点,找出当前性能瓶颈,修改,验证,以稍高于系统的当前 能力的压力进行模拟,Page 15,性能瓶颈分析性能分析的手段和方法,JVM手术刀：线程堆栈剖析 内存泄漏X光机：内存泄漏分析 虚拟机润滑油：JVM参数调优 性能调优百宝箱：性能调优工具,Page 16,性能瓶颈分析手段和方法之一线程
20、堆栈剖析,原理：通过分析JVM线程运行情况，定位性能问题 方法： kill -3 (UNIX) ctrl+break (windows) 打印出当前的虚拟机的一个运行剖面，进行分析“WorkerThread-8“ . in Object.wait() . . - locked (a Queue) . “WorkerThread-10“ . in Object.wait() . . - locked (a Queue) . “WriterThread-3“ . in Object.wait() . . - locked (a Queue) .能够发现的性能问题： (1) 资源争用 (2) 锁的粒
21、度过大 (3) sleep的滥用适用场合： 识别只有在高负载的时候才出现的性能瓶颈。 多线程场合不适用的场合： 单操作单线程下的代码段耗时分析,如一次界面点击，感觉迟缓。,有一种多线程情况下，需要关注： 绝大多数线程处于等待状态，请检查是否有关键路径，没有足够的能力产生线程任务，如：在消息分发系统，消息分发一般是一个线程，而处理是多线程，这时候消息分发是瓶颈的话，观察到的线程堆栈就会出现上面的现象。,Page 17,性能瓶颈分析手段和方法之二 内存泄漏分析,Java 程序也存在内存泄漏 内存泄漏表现(1) 长时间运行之后系统打印OutOfMemory(2) JVM 莫名其妙地 Core Dum
22、p 内存泄漏分析 通过OptimizeIt, JProfile等可以观察对象的数量和分配的位置JVM 也提供一些工具监控堆的使用情况，尽量使用。 内存泄漏避免(1) 全局集合 在对象不需要的时侯，从集合中移除(2) 缓存 不用的对象及时清理(3) Runnable对象new了就必须使用线程来Run等,Page 18,性能瓶颈分析手段和方法之三 虚拟机调优,原理： 观察垃圾回收情况并且进行调整，使JVM的垃圾回收更加平滑和高效率方法： Java 命令行中增加 verbose:gc 运行参数 Full GC 792332K-412757K(1040896K), 8.9157secs Full GC
23、 799898K-221096K(1040896K), 5.3018secs 如果每次回收完成后可用的内存持续减少则可能存在内存泄漏。 能够发现的性能问题： 垃圾回收参数设置不合理导致的严重的性能问题 内存泄漏可以调节的JVM 垃圾回收参数 IBM JDK：主要参数： -Xconcurrentbackground Xconcurrentlevel, 以及堆大小。 SUN，HP JDK 主要是 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction JVM调优是个系统工程，和运行环境主要是内存配置密切
24、相关，需要酌情配置处理适用场合： 高负载但实时性要求不高的系统，如 Web 类应用，如移动彩铃应用，以及大容量且实时性要求非常高的系统，比如呼叫类应用。,Page 19,性能瓶颈分析手段和方法之四 性能调优工具,OptimizeIt或JProfile 提供全面的内存泄漏分析，函数调用CPU时间和内存占用分析适用场合： （1） 单操作单线程下的代码段耗时分析,如一次界面点击，感觉迟缓。不适用的场合： （1）运行期间，同一段代码被不同线程执行时，由于线程是变化的，无法找出对应的线程。 （2）大容量应用下出现的瓶颈, 因为启动这个工具性能会有几十倍甚至上百倍的的性能下降，难以支撑大容量情况下的测试分
25、析。只有在大容量下出现的锁竞争也许不会出现，频繁的磁盘IO、数据库访问等导致的瓶颈也不会出现。现象不充分暴露，自然也就谈不上分析。,Page 20,性能瓶颈问题产生的源头分析,常见架构和设计问题： 同步异步使用不当 不合理的负荷分担 缺乏必要的缓冲设计 并发设计不当资源抢占, 连接池和线程池等应用不当等 效率低下的通信方式 数据库连接缓存使用不当 常见编码问题 String +，getByte()的不恰当使用：很多时侯可以使用StringBuf 过大的同步范围 语句设计不当 ,Page 21,JAVA 远程调试,虚拟机远程调试开关：-Xdebug -Xrunjdwp:transport=dt_
26、socket,server=y,address=%DEBUG_PORT%,suspend=n,打开调试开关会对JVM的运行速度有影响，仅在需要的时候才这样做,不仅可以调试本机上运行的服务器，还可以调试远程机器,suspend设为n时JVM会在打开调试端口后正常启动，若设为y则JVM启动后会等候调试器连接后才继续启动,Page 22,JAVA 远程调试,在Eclipse中打开调试配置对话框，双击左边树中Remote Java Application增加一项远程调试配置,Project：需要调试的代码所在工程 Host：服务器所在机器，可以是打开了调试端口的远程计算机 Port：前述打开的调试端口
27、，server的userconfig.bat中的缺省值是3999,Page 23,GC 参数/输出解读,下列JVM参数可用于获取gc日志-verbose:gc 或 -Xloggc:filename 一些参考资料 http:/ http:/ http:/ 24,JAVA 内存泄漏检测,2.1 java的垃圾回收机制 java虚拟机的垃圾回收算法要做两件事情。首先，它必须检测出垃圾对象。 其次，它必须回收垃圾对象所使用的堆空间并还给程序。 垃圾检测通常通过建立一个根对象的集合并且检查从这些根对象开始的可触及性来实现。 如果正在执行的程序可以访问到的根对象和某个对象之间存在引用路径，这个对象就是可触
28、及的。 对于程序来说，根对象总是可以访问的。从这些跟对象开始， 任何可以被触及的对象都被认为是“活动”对象。无法被触及的对象被认为是垃圾， 因为它们不再影响程序的未来执行。2.2 内存泄漏的产生 如果系统中存在越来越多的不再影响程序未来执行的对象，且这些对象和根对象之间存在引用路径， 内存泄漏产生了。2.3 内存泄漏的消除 根据 内存泄漏的产生 所述。发生内存泄漏要满足如下两个条件： 1. 系统中存在越来越多的不再影响程序未来执行的对象。 2. 这些对象和根对象之间存在引用路径。 从这两个条件中能很容易找出消除内存泄漏的方法：截断系统中存在的不影响程序未来执行的对象与 根对象之间的引用路径。这
29、样，这些对象就成了“垃圾”对象，jvm就能正常回收它们。,Page 25,JAVA 内存泄漏检测,常见的内存泄露 （1） 全局HashMap等容器，在对象不需要后没有及时从容器中remove掉 （2） Thread只new了，但没有start ,Page 26,Java内存泄漏的初步确定,下面是使用GC输出分析内存泄漏的原理:GC 65.233: DefNew: 12949K-1434K(13824K), 0.0122730 secs 87703K-76189K(134892K), 0.0123500 secs(87703K-76189K(134892K), 87703K表示系统使用了多少内存
30、(我们称之为当前使用内存),76189K表示进行这次垃圾回收之后使用的内存数量(我们称之为垃圾回收后内存),134892K上两个数据相减) 可以按照如下思路分析GC输出,能够初步比较准确地判断系统是否存在内存泄漏:(1) 首先要确保系统已经稳定运行(如初使化等已经完成等) (这个条件很重要)(2) 然后取一个时间段的GC 输出作为分析数据，只分析FULL GC的行，以垃圾回收后的值为分析对象(3) 然后根据GC分析内存的使用情况: A. 如果当前使用内存持续增长, 而垃圾回收后内存也持续增长, 有一直增长到Xmx设置的内存的趋势, 那么这个时侯基本上就可以断定有内存泄漏问题了.B. 如果当前使
31、用内存增长到一个值之后,又能回落, 达到一个动态平衡, 那么就没有内存泄漏的情况.,Full GC 912526K-614350K(912576K), 2.5546922 secs Full GC 912526K-623890K(912576K), 2.5777505 secs Full GC 912575K-625359K(912576K), 2.5620272 secs Full GC 912575K-648552K(912576K), 2.5632979 secs Full GC 912532K-688576K(912576K), 2.5211377 secs Full GC 91253
32、2K-714354K(912576K), 2.6212585 secs Full GC 912538K-784362K(912576K), 2.5190768 secs,（1） 只有FULL GC的行才有分析价值 （2） 只需要检查完全垃圾后剩余的内存值是否一直再增大。,Page 27,JAVA 内存泄漏精确定位,借助一些工具，如：Optimizeit JProfiler、JRockit等， 甚至可以使用Java虚拟机自带的工具HProf进行问题的定位；使用HProf的方法如下： java -Xrunhprof 其它参数 要运行的系统main函所在的类 具体的参数列表如下： Hprof usa
33、ge: -Xrunhprof:help|:=, . Option Name and Value Description Default - - - heap=dump|sites|all heap profiling all cpu=samples|times|old CPU usage off monitor=y|n monitor contention n format=a|b ascii or binary output a file= write data to file java.hprof(.txt for ascii) net=: send data over a socket
34、write to file depth= stack trace depth 4 cutoff= output cutoff point 0.0001 lineno=y|n line number in traces? y thread=y|n thread in traces? n doe=y|n dump on exit? y gc_okay=y|n GC okay during sampling y Example: java -Xrunhprof:cpu=samples,file=log.txt,depth=3 FooClass 使用HProf定位内存泄漏问题时，可以通过通过增加参数“
35、heap=sites”来输出堆栈信息到文件中， 然后通过分析堆栈信息h和线程信息来判断内存泄漏的位置；,Page 28,JAVA 内存泄漏精确定位 OptimizeIt举例,在系统运行平稳后，做一次垃圾回收，并进行标记；反复进行可能出现内存泄漏的操作，然后再进行一次垃圾回收，并按照“Diff”列进行排序（点击该列即可，该列表示相对于进行标记时的对象的增加数）；观察并记录那些对象是增加的；重复进行上面的操作，找出一直是增加的对象；这些对象将可能是导致内存泄漏的原因。双击打开一直增加的对象，将显示这些对象是由那些对象创建的,Page 29,JAVA 内存泄漏检测-OptimizeIt,使用Opti
36、mizeIt定位内存泄露确切位置的步骤：（1） 系统稳定运行一段时间，即按照从业务逻辑来讲，不应该再有大的内存需求波动。这个非常重要。 （2） 点击OptimizeIt上的垃圾回收按钮，然后马上再点mark按钮。将当前实际对象的数量作为基准点。 （3） 过一段时间（如一个小时或者更多） （4） 点击OptimizeIt上的垃圾回收按钮，检查是否有大量的对象增加，如果有增加，主要是哪些对象确定可疑范围，通过结合阅读代码进行分析。,Page 30,Unix下调试利器-Proc工具介绍,/proc文件系统不是普通意义上的文件系统，它是一个到运行中进程地址空间的访问接口。通过/proc，可以用标准Un
37、ix系统调用(比如open()、read()、write()、ioctl()等等)访问进程地址空间。 大多数Unix(/Linux)操作系统在带一系列的工具集，借助这些工具，可以对进行进行剖析，从而协助定位相关问题。,Windows下可以使用Taskinfo工具分析类似的内容 Linux下直接到/Proc下面，大部分数据可读。 可结合lsof进行分析,http:/ 31,Proc工具列表,pcredpfilespflagsplddpmapprunpsig,pstackpstopptimeptreepwaitpwdxplimit,Page 32,Proc工具介绍pstack,pstack 打印当
38、前进程的每个线程的堆栈信息,9e7932c8 scan_info (1516900, 15168b4, 1516930, b68, 800, b1c) + f89e793628 parse (1516900, 15168b4, 1516924, 1516930, 9e793544, 332a8) + e49e78cc90 init (1516948, 549, 1516900, 15168b4, 1516924, 1516930) + 1889e78cf54 LicFileParseInit (1516948, 549, 15168b4, 1516900, 1516924, 1516930)
39、+ 4c9e79d484 AdaptiveLMStandAloneInitEx (15168b4, 1516930, 9e7c8ebc, 549, 9e7a9df3, 9e7a9dfe) + 4809e78b04c AdaptiveLMStandAloneInit (1516718, 2c6f, 9e7c8ebc, 549, 9e7a9df3, 9e7a9dfe) + 2c9e78a3e0 _1cLLicenseInit6Fpkc1_i_ (64df28, 64df28, 0, 7efefeff, 81010100, ff00) + 2789e78a7c0 Java_com_huawei_u_
40、1sys_common_licmgr_LicenseIntf_nativeCheckLicense (ff33a4, 932ff308, 932ff384, 932ff380, 70, 0) + 80f980b96c ? (932ff384, b8, 0, bbd7f4d0, 0, 0),用处： 协助定位JNI/本地程序CPU使用过高，线程死锁,通过周期打印堆栈，比较前后堆栈，找出一直处于忙的线程，从而定位出可疑代码范围,打印的堆栈包含锁对象，通过检查多个线程的锁对象，从而定位出死锁位置,代码段的绝对地址,偏移量，即在该位置处调用了其它函数,函数的参数,Page 33,Proc工具介绍psta
41、ck,Solaris AIXpstack = procstack pmap = procmap Linuxpstack = lsstack pmap = pmap pfiles=lsof HPNot found,Page 34,Proc工具介绍pstack,- lwp# 14 / thread# 25 -ff369764 _sigprocmask (ff36bf60, 0, 0, e6181d70, ff37e000, 0) + 8ff35e110 _sigon (e6181d70, ff385930, 6, e6180114, e6181d70, 6) + d0ff361150 _thrp_
42、kill (0, 19, 6, ff37e000, 19, ff2c0450) + f8ff24b900 raise (6, 0, 0, ffffffff, ff2c03bc, 4) + 40ff2358ec abort (ff2bc000, e6180268, 0, fffffff8, 4, e6180289) + 100fe3c68fc _1cCosFabort6Fl_v_ (1, fe4c8000, 1, e61802e8, 0, e9f90420) + b8fe3c59f0 _1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_
43、(ff2c02ac, fe53895c, fe4dc164, fe470ab4, fe4c8000, e6180308) + 254fe20a8b4 JVM_handle_solaris_signal (0, 25d5b8, e6180d90, fe4c8000, b, e6181048) + 8ecff36b824 _sighndlr (b, e6181048, e6180d90, fe20a8cc, e6181e14, e6181e04) + cff3684d8 sigacthandler (b, e6181d70, 0, 0, 0, ff37e000) + 708- called fro
44、m signal handler with signal 11 (SIGSEGV) -e9f90420 Java_HelloWorld_displayHelloWorld (25d644, e6181224, e61819b8, 0, 2, 0) + 3000090ae4 ? (e6181224, e61819b8, 25d5b8, fe4c8000, 0, 109a0)0008dc4c ? (e61812c4, ffffffff, ffffffff, 97400, 4, e61811b8)0008dc4c ? (e618135c, e61819b8, fe4c8000, 99600, c,
45、e6181250)0008dc4c ? (e61813ec, f76a2f90, e618147c, 99600, c, e61812f8)0008ddb4 ? (e618147c, f68578b8, 0, 99974, c, e6181388)0008ddd8 ? (e618154c, e61815c8, e61815cc, 99974, 4, e6181410) - pmap output snippet:E9500000 1184K read E9680000 1392K read E9800000 4608K read E9F60000 136K read/write/exec E9
46、F90000 8K read/exec /home/usera/wls70/solaris/projectWork/lib/libhello.so E9FA0000 8K read/write/exec /home/usera/wls70/solaris/projectWork/lib/libhello.so E9FB4000 8K read/write/exec E9FC0000 120K read/exec /usr/lib/libelf.so.1 E9FEE000 8K read/write/exec /usr/lib/libelf.so.1 . Notice from the pstack output that the address where this happened is at e9f90420. The pmap output snippet shows that e9f90420 falls between E9F90000 and E9FA0000, so the error is happening somewhere within the libhello.so shared object.,Page 35,
