Java 中的 DebugBreak 等效项?

发布于 2024-11-27 02:00:24 字数 383 浏览 0 评论 0原文

我正在寻找一种从 Java 代码闯入调试器的方法,而无需在 IDE 中设置断点。

在 Win32 中,有 DebugBreak(),在 C# 中,有 DebugBreak() 等价于 C# ,但我在 Java 中找不到任何东西。

我想做的事情:假设我等待 30 秒超时,但在正常情况下,等待时间应始终小于 1 秒。我想使用 ByteMan 或类似的东西首先等待 1 秒超时,然后进入调试器,如果等待超时。

I'm looking for a way to break into the debugger from Java code, without setting a breakpoint in the IDE.

In Win32 there was DebugBreak(), in C# there's DebugBreak() Equivalent in C#, but I can't find anything in Java.

What I'm trying to do: say I have a wait with a 30s timeout, but in normal conditions that wait should always be <1s. I'd like to use ByteMan or something similar to wait with 1s timeout first, and break into the debugger if that wait timed out.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

走野 2024-12-04 02:00:24

这个问题的发布者已经完全满足了我的要求:生产 JVM 的安全调试

它重现了DebugBreak的最佳功能,即只有在“断点”被击中后,您才能将IDE附加到您的程序。

The poster of this question has done exactly what I was looking for: Secure Debugging for Production JVMs

It reproduces the best feature of DebugBreak, that is you can attach the IDE to your program only after the "breakpoint" is hit.

暮色兮凉城 2024-12-04 02:00:24

我创建了这个类

import com.sun.jna.Library;

public interface Kernel32 extends Library {

    public void OutputDebugStringA(String Text);
    public void DebugBreak();    
}

,然后像这样使用它:

Kernel32 lib = (Kernel32) Native.loadLibrary("kernel32", Kernel32.class);
lib.OutputDebugStringA("just before DebugBreak\n");
lib.DebugBreak();

就是这样。它调用本机函数
void WINAPI DebugBreak(void);
Kernel32.dll 内,

您还需要 jar 文件 jna-4.4.0.jar

I created this class

import com.sun.jna.Library;

public interface Kernel32 extends Library {

    public void OutputDebugStringA(String Text);
    public void DebugBreak();    
}

then used it like this:

Kernel32 lib = (Kernel32) Native.loadLibrary("kernel32", Kernel32.class);
lib.OutputDebugStringA("just before DebugBreak\n");
lib.DebugBreak();

and that's it. It calls native function
void WINAPI DebugBreak(void);
inside Kernel32.dll

You also need the jar file jna-4.4.0.jar

我的鱼塘能养鲲 2024-12-04 02:00:24

这不是您问题的直接答案,但在大多数 IDE 中您可以设置条件断点

这需要您在超时之前在代码中设置时间戳变量,并在超时之后在断点中测试其值。如果增量大于阈值,您将触发条件断点。

Not a direct answer to your question but in most IDE's you can set conditional breakpoints.

This would require you to set a timestamp variable in your code before the timeout and test its value in your breakpoint, after the timeout. You would trigger your breakpoint conditional if the delta is greater than your threshold.

猛虎独行 2024-12-04 02:00:24

为了在 IDE 中实现更简单的情况,还可以使用这个在主体中带有断点的示例,可怜的条件...(抱歉 c# 格式)

        if (lineNumber==6502)
        {
            System.out.println("BREAK"); //breakpoint here
        }

for easier situation inside IDE use also this example with breakpoint in body, poor mans conditional... (sorry for c# format)

        if (lineNumber==6502)
        {
            System.out.println("BREAK"); //breakpoint here
        }
感情废物 2024-12-04 02:00:24

目前(截至 2021 年),您无法在 Java 中以像 C# 中的 DebugBreak 那样方便的方式完成此操作。

在 Java 中你能做的最好的事情就是抛出一个自定义运行时异常(例如,class DebugBreakException extends RuntimeException),并祈祷你还记得添加一个“异常断点”,每当抛出此异常时该断点就会中断,即使异常被处理。

在您的代码抛出此异常后,它会立即捕获该异常并转储一条消息,表明发生了此特定异常。

如果此消息出现在日志中,但您的调试器没有中断,那么您就知道您忘记添加必要的“异常断点”。 (换句话说,你必须祈祷,如果这条消息被记录下来,就会被某人注意到。)

你也可以对此更加聪明,并添加一些代码来检查从异常发生的那一刻起已经过去了多少毫秒。抛出直到被抓住;如果经过的时间超过 10 毫秒,则很可能调试器发生了中断,因此可以跳过消息的记录。如果在不到 10 毫秒的时间内捕获异常,则调试器可能没有中断,因此您可以继续记录消息。

不言而喻,除了简单地记录消息之外,您还可以尝试采取尽可能多的其他措施,例如发出蜂鸣声、打开灯、给自己发送电子邮件、敲锣、炸主板等等。 。

Currently (as of 2021) you cannot accomplish this in Java in a way as convenient as DebugBreak is in C#.

The best you can do in Java is throw a custom runtime exception (say, class DebugBreakException extends RuntimeException) and pray that you have also remembered to add an "exception breakpoint" which breaks whenever this exception is thrown, even if the exception is handled.

Immediately after your code throws this exception, it catches it and dumps a message saying that this particular exception occurred.

If this message ever appears in the log, and yet your debugger did not break, then you know you forgot to add the necessary "exception breakpoint." (In other words, you have to pray that if this message ever gets logged, it will be noticed by someone.)

You can also be extra smart about it and add some code which checks how many milliseconds have elapsed from the moment the exception was thrown until it was caught; if more than, say, 10 milliseconds elapsed, then most probably there was a break into the debugger, so the logging of the message can be skipped. If the exception was caught within fewer than 10 milliseconds, then the debugger probably did not break, so you can proceed with logging the message.

It goes without saying that besides simply logging a message you can try to take as many additional measures as you can, like produce a beep, turn on a lamp, send an email to yourself, bang a gong, fry a motherboard, whatever it takes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文