赵怡然
我这边也有人遇到了这个问题，而且先驱（电脑端协议机器人）和mirai两个人都遇到了这个情况，而且封号时间非常统一，都在下午的14:02
经测试ktor和netty、bouncycastle经过如下混淆依然可以使得mirai正常运行，体积（apk）减少了1MB，虽然只是粗浅测试，但收发消息、重连什么的似乎没问题？（测试环境 2.7.1-dev-1） ``` # ktor -keep class io.ktor.utils.io.pool.DefaultPool { *; } #netty -keepattributes Signature,InnerClasses -keep class io.netty.bootstrap.Bootstrap { *;} -keep class io.netty.buffer.AbstractByteBufAllocator { *;} -keep class io.netty.util.ReferenceCountUtil { *; }...
> 提供 `jstack` 这是调用System.exit(0) 后的无法退出的情况 ``` 2022-04-02 13:38:20 Full thread dump OpenJDK 64-Bit Server VM (25.242-b01 mixed mode): "DefaultDispatcher-worker-4" #42 daemon prio=5 os_prio=0 tid=0x0000000057df1800 nid=0x1e00 waiting on condition [0x000000005e1ce000] java.lang.Thread.State:...
> ``` frame.addWindowListener(object : WindowAdapter() { override fun windowClosing(e: WindowEvent) { val result = JOptionPane.showConfirmDialog(null, "确认退出?退出后程序将彻底关闭，已登陆的骰娘将会离线", "确认", JOptionPane.OK_CANCEL_OPTION, JOptionPane.INFORMATION_MESSAGE) if (result == JOptionPane.OK_OPTION) { exitProcess(0) } } }) ```
这里我点击OK之后，调用exitProcess(0)，frame窗口啥的都被关了，看起来像退出了，一看任务管理器，javaw.exe还在....
> 提供一下最简复现代码 换成java.exe也是一样的，只不过是个不自动退出的控制台窗口罢了
> > 不过超时强制结束还是得有的（指强行停止console） > > 比较好的设计其实是提供一个API，通知主程序退出。（API只设置标志，主程序在合适的时间检查这个标志发起退出流程） 这样插件可以相对有序的关闭，而不要让插件自己exit。 这种行为经常会破坏其他插件的开发逻辑，造成一些现场破坏、数据完整性出问题之类的问题。 因为历史遗留问题，往往会写成 ``` try{ //插件内的退出API }catch(e){ System.exit(1) } ``` 以兼容旧版本的框架
``` Exception in coroutine 'unnamed' ExceptionInPacketCodecException(cause=java.lang.IllegalStateException: 32) at net.mamoe.mirai.internal.network.impl.netty.NettyNetworkHandler.handl eExceptionInDecoding(NettyNetworkHandler.kt:61) at net.mamoe.mirai.internal.network.impl.netty.NettyNetworkHandler$ByteB ufToIncomingPacketDecoder.channelRead0(NettyNetworkHandler.kt:83) at net.mamoe.mirai.internal.network.impl.netty.NettyNetworkHandler$ByteB ufToIncomingPacketDecoder.channelRead0(NettyNetworkHandler.kt:73) at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChanne lInboundHandler.java:99) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abst ractChannelHandlerContext.java:379) at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(Abst ractChannelHandlerContext.java:365) at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(Abstra ctChannelHandlerContext.java:357) at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMes...
可能是一种新的没有被识别的设备锁之类安全验证的数据包...
``` 问题签名: 问题事件名称: APPCRASH 应用程序名: RemoteApp Tool.exe 应用程序版本: 6.0.0.0 应用程序时间戳: 600ab067 故障模块名称: ntdll.dll 故障模块版本: 6.1.7601.17514 故障模块时间戳: 4ce7c8f9 异常代码: c00000fd 异常偏移: 0000000000057e75 OS 版本: 6.1.7601.2.1.0.256.1 区域设置 ID: 2052 其他信息 1: 207d...