某某茶叶有限公司欢迎您!
金沙棋牌在线 > 金沙棋牌在线 > JVM致命错误日志(hs_err_pid.log)分析

JVM致命错误日志(hs_err_pid.log)分析

时间:2019-12-29 06:39

当jvm出现致命错误时,会生成一个错误文件 hs_err_pid<pid>.log,其中包括了导致jvm crash的重要信息,可以通过分析该文件定位到导致crash的根源,从而改善以保证系统稳定。当出现crash时,该文件默认会生成到工作目录下,然而可以通过jvm参数指定生成路径(JDK6中引入):

最近两天测试环境有一个服务总是会挂(两到三天一次),JVM虚拟机总是会崩溃。所以有必要了解JVM崩溃的原因是什么。

configparser模块

web.config配置如下: 
<?xml version="1.0" encoding="utf-8" ?> 

-XX:ErrorFile=./hs_err_pid<pid>.log

当JVM发生致命错误导致崩溃时,会生成一个hs_err_pid_xxx.log这样的文件,该文件包含了导致 JVM crash 的重要信息,我们可以通过分析该文件定位到导致 JVM Crash 的原因,从而修复保证系统稳定。

该模块适用于配置文件的格式与windows ini文件类似,可以包含一个或多个节(section),每个节可以有多个参数(键=值)。字典一样.

<configuration> 
<configSections> 
  <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" /> 
</configSections> 
<log4net> 
  <!--错误日志配置--> 
  <appender name="ErrorAppender" type="log4net.Appender.RollingFileAppender"> 
   <param name="File" value="Log\LogError\" />   
   <param name="AppendToFile" value="true" /> 
   <param name="MaxSizeRollBackups" value="100" /> 
   <param name="MaxFileSize" value="10240" /> 
   <param name="StaticLogFileName" value="false" /> 
   <param name="DatePattern" value="yyyyMMdd" /> 
   <param name="RollingStyle" value="Date" /> 
   <layout type="log4net.Layout.PatternLayout"> 
    <param name="ConversionPattern" value="%n异常时间:%d [%t] %n异常级别:%-5p %n异 常 类:%c [%x] %n%m %n " /> 
   </layout> 
  </appender>

该文件包含如下几类关键信息:

默认情况下,该文件是生成在工作目录下的,当然也可以通过 JVM 参数指定生成路径:

import configparser

config = configparser.ConfigParser()

config["DEFAULT"] = {'ServerAliveInterval': '45',
                      'Compression': 'yes',
                     'CompressionLevel': '9',
                     'ForwardX11':'yes'
                     }

config['bitbucket.org'] = {'User':'hg'}

config['topsecret.server.com'] = {'Host Port':'50022','ForwardX11':'no'}

with open('example.ini', 'w') as configfile:

   config.write(configfile)

  <!--信息日志配置--> 
  <appender name="InfoAppender" type="log4net.Appender.RollingFileAppender"> 
   <param name="File" value="Log\LogInfo\" /> 
   <param name="AppendToFile" value="true" /> 
   <param name="MaxFileSize" value="10240" /> 
   <param name="MaxSizeRollBackups" value="100" /> 
   <param name="StaticLogFileName" value="false" /> 
   <param name="DatePattern" value="yyyyMMdd" /> 
   <param name="RollingStyle" value="Date" /> 
   <layout type="log4net.Layout.PatternLayout"> 
    <param name="ConversionPattern" value="%n日志时间:%d [%t] %n日志级别:%-5p %n日 志 类:%c [%x] %n%m %n" /> 
   </layout> 
  </appender>   
  <!--控制台--> 
  <appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender"> 
   <layout type="log4net.Layout.PatternLayout"> 
    <conversionPattern value="%5level [%thread] (%file:%line) - %message%newline" /> 
   </layout> 
  </appender>

  • 日志头文件
  • 导致crash的线程信息
  • 所有线程信息
  • 安全点和锁信息
  • 堆信息
  • 本地代码缓存
  • 编译事件
  • gc相关记录
  • jvm内存映射
  • jvm启动参数
  • 服务器信息
-XX:ErrorFile=/var/log/hs_err_pid<pid>.log

执行该代码会在与py文件的相同目录下增加一个.ini后缀的文件。如果有则覆盖,所以我们在日常使用中看到.ini后缀的文件就是存放数据,配置文件的

  <!--log4net.LogManager.GetLogger("logerror")用这个来选择这种类型--> 
  <logger name="logerror"> 
   <level value="ERROR" /> 
   <appender-ref ref="ErrorAppender" /> 
  </logger> 
  <logger name="loginfo"> 
   <level value="INFO" /> 
   <appender-ref ref="InfoAppender" /> 
  </logger>   
  <root> 
   <level value="INFO" /> 
   <appender-ref ref="InfoAppender" /> 
   <appender-ref ref="ConsoleAppender" /> 
  </root> 
</log4net> 
</configuration>

下面用一个crash demo文件逐步解读这些信息,以便大家以后碰到crash时方便分析。

这个文件主要包含如下内容:

文件

 

日志头文件

日志头文件包含概要信息,简述了导致crash的原因。而导致crash的原因很多,常见的原因有jvm自身的bug,应用程序错误,jvm参数配置不当,服务器资源不足,jni调用错误等。

现在参考下如下描述:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fb8b18fdc6c, pid=191899, tid=140417770411776
#
# JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J  org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

这里一个重要信息是“SIGSEGV(0xb)”表示jvm crash时正在执行jni代码,而不是在执行java或者jvm的代码,如果没有在应用程序里手动调用jni代码,那么很可能是JIT动态编译时导致的该错误。其中SIGSEGV是信号名称,0xb是信号码,pc=0x00007fb8b18fdc6c指的是程序计数器的值,pid=191899是进程号,tid=140417770411776是线程号。

PS:除了“SIGSEGV(0xb)”以外,常见的描述还有“EXCEPTION_ACCESS_VIOLATION”,该描述表示jvm crash时正在执行jvm自身的代码,这往往是因为jvm的bug导致的crash;另一种常见的描述是“EXCEPTION_STACK_OVERFLOW”,该描述表示这是个栈溢出导致的错误,这往往是应用程序中存在深层递归导致的。

还有一个重要信息是:

# Problematic frame:

# J org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;

这表示出现crash时jvm正在执行的代码,这里的“J”表示正在执行java代码,后面的表示执行的方法栈。除了“J”外,还有可能是“C”、“j”、“V”、“v”,它们分别表示:

  • C: Native C frame
  • j: Interpreted Java frame
  • V: VMframe
  • v: VMgenerated stub frame
  • J: Other frame types, including compiled Java frames

加上前面对SIGSEGV(0xb)”的分析,现在可以断定是JIT动态编译导致的该错误。

查阅资料发现:

此异常是由于jdk JIT compiler optimization 导致,bug id 8021898,官网描述如下:

The JIT compiler optimization leads to a SIGSEGV or an NullPointerException at a place it must not happen.

jdk1.7.0_25到1.7.0_55这几个版本都存在此bug,1.7.0_60后修复。可通过升级jdk解决此异常,可参考 。

到这里该问题已经分析出原因了,但是咱们可以再深入一步,分析下其它信息。

  • 日志头文件
  • 导致 crash 的线程信息
  • 所有线程信息
  • 安全点和锁信息
  • 堆信息
  • 本地代码缓存
  • 编译事件
  • gc 相关记录
  • jvm 内存映射
  • jvm 启动参数
  • 服务器信息

图片 1

LOG操作类 
using System;   
using System.IO;      

导致crash的线程信息

文件下面是导致crash的线程信息和该线程栈信息,描述信息如下:

Current thread (0x00007fb7b4014800):  JavaThread "catalina-exec-251" daemon [_thread_in_Java, id=205044, stack(0x00007fb58f435000,0x00007fb58f536000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000003f96dc9c6c

以上表示导致出错的线程是0x00007fb7b4014800(指针),线程类型是JavaThread,JavaThread表示执行的是java线程,关于该线程其它类型还可能是:

  • VMThread:jvm的内部线程
  • CompilerThread:用来调用JITing,实时编译装卸class 。 通常,jvm会启动多个线程来处理这部分工作,线程名称后面的数字也会累加,例如:CompilerThread1
  • GCTaskThread:执行gc的线程
  • WatcherThread:jvm周期性任务调度的线程,是一个单例对象。 该线程在JVM内使用得比较频繁,比如:定期的内存监控、JVM运行状况监控,还有我们经常需要去执行一些jstat 这类命令查看gc的情况
  • ConcurrentMarkSweepThread:jvm在进行CMS GC的时候,会创建一个该线程去进行GC,该线程被创建的同时会创建一个SurrogateLockerThread(简称SLT)线程并且启动它,SLT启动之后,处于等待阶段。CMST开始GC时,会发一个消息给SLT让它去获取Java层Reference对象的全局锁:Lock

后面的”catalina-exec-251″表示线程名,带有catalina前缀的线程一般是tomcat启动的线程,“daemon”表示该线程为守护线程,再后面的“[_thread_in_Java”表示线程正在执行解释或者编译后的Java代码,关于该描述其它类型还可能是:

  • _thread_in_native:线程当前状态
  • _thread_uninitialized:线程还没有创建,它只在内存原因崩溃的时候才出现
  • _thread_new:线程已经被创建,但是还没有启动
  • _thread_in_native:线程正在执行本地代码,一般这种情况很可能是本地代码有问题
  • _thread_in_vm:线程正在执行虚拟机代码
  • _thread_in_Java:线程正在执行解释或者编译后的Java代码
  • _thread_blocked:线程处于阻塞状态
  • …_trans:以_trans结尾,线程正处于要切换到其它状态的中间状态

最后的“id=205044”表示线程ID,stack(0x00007fb58f435000,0x00007fb58f536000)表示栈区间。

“siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000003f96dc9c6c”这部分是导致虚拟机终止的非预期的信号信息:其中si_errno和si_code是Linux下用来鉴别异常的,Windows下是一个ExceptionCode。

下面就根据这个文件内容逐步解析。

该文件的内容如上图,**因为在写入文件的时候是‘w’所以每次运行会覆盖ini中的内容,如果想要不删除则改成‘a’追加模式即可

    /**//// <summary>   
    /// LogHelper的摘要说明。   
    /// </summary>   
    public class LogHelper   
    {   
        private SystemLog()   
        {   
        }   
  
        public static readonly log4net.ILog loginfo = log4net.LogManager.GetLogger("loginfo");   //选择<logger name="loginfo">的配置 
   
        public static readonly log4net.ILog logerror = log4net.LogManager.GetLogger("logerror");   //选择<logger name="logerror">的配置 
   
        public static void SetConfig()   
        {   
            log4net.Config.XmlConfigurator.Configure();   
        }   
  
        public static void SetConfig(FileInfo configFile)   
        {   
            log4net.Config.XmlConfigurator.Configure(configFile);    
        }   
  
        public static void WriteLog(string info)   
        {   
            if(loginfo.IsInfoEnabled)   
            {   
                loginfo.Info(info);   
            }   
        }   
  
        public static void WriteLog(string info,Exception se)   
        {   
            if(logerror.IsErrorEnabled)   
            {   
                logerror.Error(info,se);   
            }   
        }   
    } 

所有线程信息

再下面是线程信息:

Java Threads: ( => current thread )
  0x00007fb798015800 JavaThread "catalina-exec-280" daemon [_thread_blocked, id=206093, stack(0x00007fb58d718000,0x00007fb58d819000)]
  0x00007fb7a4016800 JavaThread ”catalina-exec-279″ daemon [_thread_blocked, id=206091, stack(0x00007fb58d819000,0x00007fb58d91a000)]
  … …(省略)

  Other Threads:
  0x00007fb8b4231000 VMThread [stack: 0x00007fb854eb6000,0x00007fb854fb7000] [id=192015]
  0x00007fb8b4321000 WatcherThread [stack: 0x00007fb835e6c000,0x00007fb835f6d000] [id=192414]

信息和上面介绍的类似,其中[_thread_blocked表示线程阻塞。

日志头文件

内容如下

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000003797807a91, pid=29071, tid=139901421901568
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

这段内容主要简述了导致 JVM Crash 的原因。常见的原因有 JVM 自身的 bug,应用程序错误,JVM 参数,服务器资源不足,JNI 调用错误等。当然还有一些版本和配置信息,

SIGSEGV (0xb) at pc=0x0000003797807a91, pid=29071, tid=139901421901568

非预期的错误被 JRE 检测到了,其中

  • SIGSEGV :信号量
  • 0xb :信号码
  • pc=0x0000003797807a91 :程序计数器的值
  • pid=29071 :进程号
  • tid=139901421901568 :线程号

SIGSEGV(0xb) 表示 JVM Crash 时正在执行 JNI 代码,常见的描述还有EXCEPTION_ACCESS_VIOLATION,该描述表示 JVM Crash 时正在执行 JVM 自身的代码,这往往是因为 JVM 的 Bug 导致的 Crash;另一种常见的描述是EXCEPTION_STACK_OVERFLOW,该描述表示这是个栈溢出导致的错误,这往往是应用程序中存在深层递归导致的。

# JRE version: Java(TM) SE Runtime Environment (8.0_45-b14) (build 1.8.0_45-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode linux-amd64 compressed oops)

JRE 和 JVM 的版本信息

# Problematic frame:
# C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1

这个信息比较重要,问题帧信息:

C 表示帧类型为本地帧,还有其他类型:

  • j : 解释的Java帧
  • V : 虚拟机帧
  • v :虚拟机生成的存根栈帧
  • J:其他帧类型,包括编译后的Java帧

[libresolv.so.2+0x7a91] __libc_res_nquery+0x1c1和程序计数器(pc)表达的含义一样,但是用的是本地so库+偏移量的方式。

此外还可以进行删改查操作

Global.asax.cs文件配置如下:

安全点和锁信息

再下面是安全点和锁信息:

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

安全线信息为正常运行,其它可能得描述还有:

  • not at a safepoint:正常运行状态
  • at safepoint:所有线程都因为虚拟机等待状态而阻塞,等待一个虚拟机操作完成
  • synchronizing:一个特殊的虚拟机操作,要求虚拟机内的其它线程保持等待状态

锁信息为未被线程持有,Mutex是虚拟机内部的锁,而Monitor则是synchronized锁或者其它关联到的Java对象。

导致 crash 的线程信息

内容如下:

---------------  T H R E A D  ---------------

Current thread (0x0000000001e94800):  JavaThread "pool-1-thread-2" [_thread_in_native, id=30111, stack(0x00007f3d567e5000,0x00007f3d568e6000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000003

Registers:
RAX=0x0000000000000000, RBX=0x0000000000000000, RCX=0x0000000000000000, RDX=0x0000000000000050
RSP=0x00007f3d568e2280, RBP=0x00007f3d568e2570, RSI=0x0000000000000000, RDI=0x00000000ffffffff
R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x000000000007a337, R11=0x0000000000000213
R12=0x00007f3d568e2ef0, R13=0x00007f3d568e22b0, R14=0x0000000000000000, R15=0x00007f3d568e5db8
RIP=0x0000003797807a91, EFLAGS=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f3d568e2280)
0x00007f3d568e2280:   b8e4bfb900000800 00007f3d568e3760
0x00007f3d568e2290:   00007f3d568e3758 00007f3d568e377c
0x00007f3d568e22a0:   00007f3d568e3778 6f6e6b6e56a88a58
0x00007f3d568e22b0:   00000100000149a0 7a68710800000000
0x00007f3d568e22c0:   6970067363642d78 6d6f63036e61676e
....省略

Instructions: (pc=0x0000003797807a91)
0x0000003797807a71:   48 89 45 b8 48 8b 4d b8 0f b6 51 03 89 d3 83 e3
0x0000003797807a81:   0f 75 0d 0f b7 49 06 66 c1 c9 08 66 85 c9 75 4f
0x0000003797807a91:   0f b6 48 03 bf 0f 00 00 00 40 20 cf 75 0d 0f b7
0x0000003797807aa1:   70 06 66 c1 ce 08 66 85 f6 75 34 83 e1 0f 83 e2 

Register to memory mapping:

RAX=0x0000000000000000 is an unknown value
RBX=0x0000000000000000 is an unknown value
RCX=0x0000000000000000 is an unknown value
RDX=0x0000000000000050 is an unknown value
RSP=0x00007f3d568e2280 is pointing into the stack for thread: 0x0000000001e94800
RBP=0x00007f3d568e2570 is pointing into the stack for thread: 0x0000000001e94800
... 省略


Stack: [0x00007f3d567e5000,0x00007f3d568e6000],  sp=0x00007f3d568e2280,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1
C  [libresolv.so.2+0x7fd1]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 15056  java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress; (0 bytes) @ 0x00007f3d7492af8c [0x00007f3d7492af40+0x4c]
J 14966 C1 java.net.InetAddress.getAddressesFromNameService(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (245 bytes) @ 0x00007f3d75466754 [0x00007f3d754662c0+0x494]
J 14291 C2 java.net.InetAddress.getAllByName(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (387 bytes) @ 0x00007f3d7534b718 [0x00007f3d7534ae20+0x8f8]
J 14178 C1 java.net.InetSocketAddress.<init>(Ljava/lang/String;I)V (47 bytes) @ 0x00007f3d752ce0f4 [0x00007f3d752cdec0+0x234]
j  sun.security.ssl.SSLSocketImpl.<init>(Lsun/security/ssl/SSLContextImpl;Ljava/lang/String;ILjava/net/InetAddress;I)V+144
j  sun.security.ssl.SSLSocketFactoryImpl.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+13
j  com.ufclub.daq.qhzx.utils.SSLProtocolSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+15
.... 省略代码

这部分内容包含出发 JVM 致命错误的线程详细信息和线程栈。

线程信息

Current thread (0x0000000001e94800):  JavaThread "pool-1-thread-2" [_thread_in_native, id=30111, stack(0x00007f3d567e5000,0x00007f3d568e6000)]
  • 0x0000000001e94800:出错的线程指针
  • JavaThread:线程类型,可能的类型包括
  1. JavaThread:Java线程
  2. VMThread : JVM 的内部线程
  3. CompilerThread:用来调用JITing,实时编译装卸class 。 通常,jvm会启动多个线程来处理这部分工作,线程名称后面的数字也会累加,例如:CompilerThread1
  4. GCTaskThread:执行gc的线程
  5. WatcherThread:JVM 周期性任务调度的线程,是一个单例对象
  6. ConcurrentMarkSweepThread:jvm在进行CMS GC的时候,会创建一个该线程去进行GC,该线程被创建的同时会创建一个SurrogateLockerThread(简称SLT)线程并且启动它,SLT启动之后,处于等待阶段。CMST开始GC时,会发一个消息给SLT让它去获取Java层Reference对象的全局锁:Lock
  • pool-1-thread-2:线程名称
  • _thread_in_native:当前线程状态。该描述还包含有:
  1. _thread_in_native:线程当前状态,状态枚举包括:
  2. _thread_uninitialized:线程还没有创建,它只在内存原因崩溃的时候才出现
  3. _thread_new:线程已经被创建,但是还没有启动
  4. _thread_in_native:线程正在执行本地代码,一般这种情况很可能是本地代码有问题
  5. _thread_in_vm:线程正在执行虚拟机代码
  6. _thread_in_Java:线程正在执行解释或者编译后的Java代码
  7. _thread_blocked:线程处于阻塞状态
  8. …_trans:以_trans结尾,线程正处于要切换到其它状态的中间状态
  • id=30111:线程ID
  • stack(0x00007f3d567e5000,0x00007f3d568e6000):栈区间
siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000003

表示导致虚拟机终止的非预期的信号信息。

Top of Stack: (sp=0x00007f3d568e2280)
0x00007f3d568e2280:   b8e4bfb900000800 00007f3d568e3760
0x00007f3d568e2290:   00007f3d568e3758 00007f3d568e377c
0x00007f3d568e22a0:   00007f3d568e3778 6f6e6b6e56a88a58
0x00007f3d568e22b0:   00000100000149a0 7a68710800000000
0x00007f3d568e22c0:   6970067363642d78 6d6f63036e61676e
....省略

Instructions: (pc=0x0000003797807a91)
0x0000003797807a71:   48 89 45 b8 48 8b 4d b8 0f b6 51 03 89 d3 83 e3
0x0000003797807a81:   0f 75 0d 0f b7 49 06 66 c1 c9 08 66 85 c9 75 4f
0x0000003797807a91:   0f b6 48 03 bf 0f 00 00 00 40 20 cf 75 0d 0f b7
0x0000003797807aa1:   70 06 66 c1 ce 08 66 85 f6 75 34 83 e1 0f 83 e2 

栈顶程序计数器旁的操作码,它们可以被反汇编成系统崩溃前执行的指令。

Stack: [0x00007f3d567e5000,0x00007f3d568e6000],  sp=0x00007f3d568e2280,  free space=1012k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libresolv.so.2+0x7a91]  __libc_res_nquery+0x1c1
C  [libresolv.so.2+0x7fd1]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 15056  java.net.Inet6AddressImpl.lookupAllHostAddr(Ljava/lang/String;)[Ljava/net/InetAddress; (0 bytes) @ 0x00007f3d7492af8c [0x00007f3d7492af40+0x4c]
J 14966 C1 java.net.InetAddress.getAddressesFromNameService(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (245 bytes) @ 0x00007f3d75466754 [0x00007f3d754662c0+0x494]
J 14291 C2 java.net.InetAddress.getAllByName(Ljava/lang/String;Ljava/net/InetAddress;)[Ljava/net/InetAddress; (387 bytes) @ 0x00007f3d7534b718 [0x00007f3d7534ae20+0x8f8]
J 14178 C1 java.net.InetSocketAddress.<init>(Ljava/lang/String;I)V (47 bytes) @ 0x00007f3d752ce0f4 [0x00007f3d752cdec0+0x234]
j  sun.security.ssl.SSLSocketImpl.<init>(Lsun/security/ssl/SSLContextImpl;Ljava/lang/String;ILjava/net/InetAddress;I)V+144
j  sun.security.ssl.SSLSocketFactoryImpl.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+13
j  com.ufclub.daq.qhzx.utils.SSLProtocolSocketFactory.createSocket(Ljava/lang/String;ILjava/net/InetAddress;I)Ljava/net/Socket;+15
.... 省略代码

线程栈信息。包含了地址、栈顶、栈计数器和线程尚未使用的栈信息。到这里就基本上已经确定了问题所在原因了。

import configparser

config = configparser.ConfigParser()

#---------------------------查找文件内容,基于字典的形式

print(config.sections())        #  []

config.read('example.ini')

print(config.sections())        #   ['bitbucket.org', 'topsecret.server.com']

print('bytebong.com' in config) # False
print('bitbucket.org' in config) # True


print(config['bitbucket.org']["user"])  # hg

print(config['DEFAULT']['Compression']) #yes

print(config['topsecret.server.com']['ForwardX11'])  #no


print(config['bitbucket.org'])          #<Section: bitbucket.org>

for key in config['bitbucket.org']:     # 注意,有default会默认default的键
    print(key)

print(config.options('bitbucket.org'))  # 同for循环,找到'bitbucket.org'下所有键

print(config.items('bitbucket.org'))    #找到'bitbucket.org'下所有键值对

print(config.get('bitbucket.org','compression')) # yes       get方法Section下的key对应的value

protected void Application_Start(Object sender, EventArgs e)   
  {   
            SystemLog.SetConfig();   
  }   
  protected void Application_Error(Object sender, EventArgs e)   
  {   
   Exception objExp = HttpContext.Current.Server.GetLastError();   
   LogHelper.WriteLog("rn客户机IP:"+ Request.UserHostAddress +"rn错误地址:"+ Request.Url +"rn异常信息:"+ Server.GetLastError().Message,objExp);   
  }  
protected void Application_Start(Object sender, EventArgs e) 
  { 
            SystemLog.SetConfig(); 
  } 
  protected void Application_Error(Object sender, EventArgs e) 
  { 
   Exception objExp = HttpContext.Current.Server.GetLastError(); 
   LogHelper.WriteLog("rn客户机IP:"+ Request.UserHostAddress +"rn错误地址:"+ Request.Url +"rn异常信息:"+ Server.GetLastError().Message,objExp); 
  }