Java Agent 踩坑之 appendToSystemClassLoaderSearch 问题-低调大师

Java Agent 踩坑之 appendToSystemClassLoaderSearch 问题

2022-06-29 443

作者： 鲁严波

从 Java Agent 报错开始，到 JVM 原理，到 glibc 线程安全，再到 pthread tls，逐步探究 Java Agent 诡异报错。

背景

由于阿里云多个产品都提供了 Java Agent 给用户使用，在多个 Java Agent 一起使用的场景下，造成了总体 Java Agent 耗时增加，各个 Agent 各自存储，导致内存占用、资源消耗增加。

MSE 发起了 one-java-agent 项目，能够协同各个 Java Agent；同时也支持更加高效、方便的字节码注入。

其中，各个 Java Agent 作为 one-java-agent 的 plugin，在 premain 阶段是通过多线程启动的方式来加载，从而将启动速度由 O(n)降低到 O(1)，降低了整体 Java Agent 整体的加载时间。

问题

但最近在新版 Agent 验证过程中，one-java-agent 的 premain 阶段，发现有如下报错：

2022-06-15 06:22:47 [oneagent plugin arms-agent start] ERROR c.a.o.plugin.PluginManagerImpl -start plugin error, name: arms-agent
com.alibaba.oneagent.plugin.PluginException: start error, agent jar::/home/admin/.opt/ArmsAgent/plugins/ArmsAgent/arms-bootstrap-1.7.0-SNAPSHOT.jar
  at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:113)
  at com.alibaba.oneagent.plugin.PluginManagerImpl.startOnePlugin(PluginManagerImpl.java:294)
  at com.alibaba.oneagent.plugin.PluginManagerImpl.access$200(PluginManagerImpl.java:22)
  at com.alibaba.oneagent.plugin.PluginManagerImpl$2.run(PluginManagerImpl.java:325)
  at java.lang.Thread.run(Thread.java:750)
Caused by: java.lang.InternalError: null
  at sun.instrument.InstrumentationImpl.appendToClassLoaderSearch0(Native Method)
  at sun.instrument.InstrumentationImpl.appendToSystemClassLoaderSearch(InstrumentationImpl.java:200)
  at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:100)
  ... 4 common frames omitted
2022-06-16 09:51:09 [oneagent plugin ahas-java-agent start] ERROR c.a.o.plugin.PluginManagerImpl -start plugin error, name: ahas-java-agent
com.alibaba.oneagent.plugin.PluginException: start error, agent jar::/home/admin/.opt/ArmsAgent/plugins/ahas-java-agent/ahas-java-agent.jar
  at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:113)
  at com.alibaba.oneagent.plugin.PluginManagerImpl.startOnePlugin(PluginManagerImpl.java:294)
  at com.alibaba.oneagent.plugin.PluginManagerImpl.access$200(PluginManagerImpl.java:22)
  at com.alibaba.oneagent.plugin.PluginManagerImpl$2.run(PluginManagerImpl.java:325)
  at java.lang.Thread.run(Thread.java:855)
Caused by: java.lang.IllegalArgumentException: null
  at sun.instrument.InstrumentationImpl.appendToClassLoaderSearch0(Native Method)
  at sun.instrument.InstrumentationImpl.appendToSystemClassLoaderSearch(InstrumentationImpl.java:200)
  at com.alibaba.oneagent.plugin.TraditionalPlugin.start(TraditionalPlugin.java:100)
  ... 4 common frames omitted

熟悉 Java Agent 的同学可能能注意到，这是调用 Instrumentation.appendToSystemClassLoaderSearch 报错了。

但首先 appendToSystemClassLoaderSearch 的路径是存在的；其次，这个报错的真实原因是在 C++部分，比较难排查。

但不管怎样，还是要深究下为什么出现这个错误。

首先我们梳理下具体的调用流程，下面的分析都是基于此来分析的：

- Instrumentation.appendToSystemClassLoaderSearch (java)
  - appendToClassLoaderSearch0 (JNI)
     `- appendToClassLoaderSearch
       |- AddToSystemClassLoaderSearch
       |  `-create_class_path_zip_entry
       |      `-stat
       `-convertUft8ToPlatformString
        `- iconv

打日志、确定现场

因为这个问题在容器环境下，有 10% 的概率出现，比较容易复现，于是就用 dragonwell8 的最新代码，加日志，确认下现场。

首先在 JNI 的实际入口处，也就是 appendToClassLoaderSearch 的方法入口添加日志：

加了上面的日志后，发现问题更加令人头秃了：

没有报错的时候，appendToClassLoaderSearch entry 会输出。
有报错的时候，appendToClassLoaderSearch entry 反而没有输出，没执行到这儿？

这个和报错的日志对不上啊，难道是 stacktrace 信息骗了我们？

过了难熬的一晚上后，第二天请教了 dragonwell 的同学，大佬打日志的姿势是这样的：

tty->print_cr("internal error");
如果上面用不了，再用 printf("xxx\n");fflush(stdout);

这样加日志后，果然我们的日志都能打出来了。

这是踩的第一个坑，printf 要加上 fflush 才能保证输出成功。

分析代码

后面又是不断加日志，最终发现 create_class_path_zip_entry 返回 NULL。

找不到对应的 jar 文件？

继续排查，发现是 stat 报错，返回 No such file or directory。但是前面也提到了，jarFile 的路径是存在的，难道 stat 不是线程安全的？

查了下文档 [ 1] ，发现 stat 是线程安全的。

于是又回过头来再看，这时候注意到 stat 的路径是不正常的：有的时候路径是空，有的时候路径是/home/admin/.opt/ArmsAgent/plugins/ahas-java-agent/ahas-java-agent.jarSHOT.jar，从字符末尾可以看到，基本上是因为两个字符写到了同一片内存导致的；而且对应字符串长度也变成了一个不规律的数字了。

那么问题就很明确了，开始查找这个字符串的生成。这个字符是 convertUft8ToPlatformString 生成的。

字符编码转换有问题？

于是开始调试 utf8ToPlatform 的逻辑，这时候为了避免频繁加日志、重启容器，所以直接在 ECS 上运行 gdb 调试 jvm。

结果发现，在 Linux 下，utf8ToPlatform 就是直接 memcpy，而且 memcpy 的目标地址是在栈上。

这怎么看都不太可能有线程安全问题啊？

后来仔细查了下，发现和环境变量有关，ECS 上编码相关的环境变量是 LANG=en_US.UTF-8，在容器上 centos:7 默认没有这个环境变量，此种情况下，jvm 读到的是 ANSI_X3.4-1968。

这儿是第二个坑，环境变量会影响本地编码转换。

结合如上现象和代码，发现在容器环境下，还是要经过 iconv，从 UTF-8 转到 ANSI_X3.4-1968 编码的。

其实，这儿也可以推测出来，如果手动在容器中设置了 LANG=en_US.UTF-8，这个问题就不会再出现。额外的验证也证实了这点。

然后又加日志，最终确认是 iconv 的时候，目标字符串写挂了。

难道是 iconv 线程不安全？

iconv不是线程安全的！

查一下 iconv 的文档，发现它不是完全线程安全的：

通俗的说，iconv 之前，需要先用 iconv_open 打开一个 iconv_t，而且这个 iconv_t，不支持多线程同时使用。

至此，问题已经差不多定位清楚了，因为 jvm 把 iconv_t 写成了全局变量，这样在多个线程 append 的时候，就有可能同时调用 iconv，导致竞态问题。

这儿是第三个坑，iconv 不是线程安全的。

如何修复

先修复 one-java-agent

对于 Java 代码，非常容易修改，只需要加一个锁就可以了：

但是这儿有一个设计问题，instrument 对象已经在代码中到处散落了，现在突然要加一个锁，几乎所有用到的地方都要改，代码改造成本比较大。

于是最终还是通过 proxy 类来解决：

这样其他地方就只需要使用 InstrumentationWrapper 就可以了，也不会触发这个问题。

jvm要不要修复

然后我们分析下 jvm 侧的代码，发现就是因为 iconv_t 不是线程安全的，导致 appendToClassLoaderSearch0 方法不是线程安全的，那能不能优雅的解决掉呢？

如果是 Java 程序，直接用 ThreadLoal 来存储 iconv_t 就能解决了。

但是 cpp 这边，虽然 C++ 11 支持 thread_local，但首先 jdk8 还没用 C++ 11（这个可以参考 JEP ）；其次，C++ 11 的也仅仅支持 thread_local 的 set 和 get，thread_local 的初始化、销毁等生命周期管理还不支持，比如没办法在线程结束时自动回收 iconv_t 资源。

那咱们就 fallback 到 pthread？因为 pthread 提供了 thread-specific data，可以做类似的事情。

pthread_key_create 创建 thread-local storage 区域
pthread_setspecific 用于将值放入 thread-local storage
pthread_getspecific 用于从 thread-local storage 取出值
最重要的，pthread_once 满足了 pthread_key_t 只能初始化一次的需求。
另外也需要提到的，pthread_once 的第二个参数，就是线程结束时的回调，我们就可以用它来关闭 iconv_t，避免资源泄漏。

总之 pthread 提供了 thread_local 的全生命周期管理。于是，最终代码如下，用 make_key 初始化 thread-local storage：

于是编译 JDK 之后，打镜像、批量重启数次 pod，就没有再出现文章开头提到的问题了。

总结

在整个过程中，从 Java 到 JNI/JVMTi，再到 glibc，再到 pthread，踩了很多坑：

printf 要加上 fflush 才能保证输出成功
环境变量会影响本地字符编码转换
iconv 不是线程安全的
使用 pthread thread-local storage 来实现线程局部变量的全生命周期管理

从这个案例中，沿着调用栈、代码，逐步还原问题、并提出解决方案，希望大家能对 Java/JVM 多了解一点。

参考链接：

[1] 文档：

https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html

[2] one-java-agent 修复的链接：

https://github.com/alibaba/one-java-agent/issues/31

[3] dragonwell 修复的链接：

https://github.com/alibaba/dragonwell8/pull/346

[4] one-java-agent 给大家带来了更加方便、无侵入的微服务治理方式：

https://www.aliyun.com/product/aliware/mse

MSE 注册配置中心专业版首购享 9 折优惠，MSE 云原生网关预付费全规格享 85 折优惠。点击“此处”，即刻享受优惠！

微信关注我们

原文链接：https://my.oschina.net/u/3874284/blog/5546873

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

PyPI 官方仓库遭遇挖矿恶意组件投毒

报告来源：OSCS开源安全社区报告作者：OSCS 更新日期：2022-06-28 事件简述 2022 年 06 月 27 日，OSCS 监测发现 PyPI 官方仓库被 ivanpoopoo 上传了 arduino、beautfulsoup、randam、pilloe、pilow、selemium 等恶意组件包。引用这些恶意组件包后会在用户电脑上下载脚本进行挖矿，该事件较为严重，OSCS 官方提醒广大开发者关注。 PIP 是 Python 包管理工具，提供了对第三方 Python 包的查找、下载、安装、卸载等功能。攻击者 ivanpoopoo 通过模仿 pillow， selenium 等知名软件包进行钓鱼，当用户安装并调用攻击者的恶意包（如 selemium.py ）时，攻击者会在用户机器上去下载并启动一个“挖矿程序”。目前 PyPI 官方已经删除该恶意组件，但国内各大镜像站如豆瓣，清华等并未及时删除恶意组件，提醒广大开发者关注。投毒分析攻击者通过模仿 beautifulsoup，pillow，selenium 等知名组件上传名称相似的恶意组件进行钓鱼攻击。OSCS 通过分...

2022-06-30

435

作者：CSDN云原生近日，阿里云 aPaaS&Serverless 前端技术专家袁坤在 CSDN 云原生 meetup 长沙站分享了 Serverless 在阿里云函数计算 FC 的实践。互联网软件架构演进我们先简单回顾下互联网软件架构的演进之路。单机部署在单机部署中，将所有的业务和数据库都部署在一台主机中。此架构的优点是：开发、部署以及运维都非常简单。缺点是：一旦遇到流量过大或者机器故障，整个系统瘫痪，甚至丢失业务数据，造成巨大业务损失。集群化部署针对上述架构问题，常用的解决方案是采取水平扩容的方式进行集群化部署。引入 SLB 的流量网关路由，进行负载均衡。集群化部署本质上是单体架构，开发人员在项目开发的时候需要额外注意，比如要使用 cookie 进行鉴权，session 就不能存储在本地，需要引入 Redis 进行单独存储。集群化部署可以通过快速水平扩容解决流量突增或机器故障的问题。微服务拆分随着业务的发展以及团队规模的扩张，单体架构这样紧耦合的方式会带来越来越多的问题，架构的灵活性和可扩展性成为阻碍业务发展的重大挑战。微服务架构应运而生。对比单体架构...

2022-06-29

427

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。