debugbreak

Is there a portable equivalent to DebugBreak()/__debugbreak?

由 萝らか妹 提交于 2020-01-19 03:18:34
问题 In MSVC, DebugBreak() or __debugbreak cause a debugger to break. On x86 it is equivalent to writing "_asm int 3", on x64 it is something different. When compiling with gcc (or any other standard compiler) I want to do a break into debugger, too. Is there a platform independent function or intrinsic? I saw the XCode question about that, but it doesn't seem portable enough. Sidenote: I mainly want to implement ASSERT with that, and I understand I can use assert() for that, but I also want to

Is there a portable equivalent to DebugBreak()/__debugbreak?

由 谁说胖子不能爱 提交于 2020-01-19 03:18:04
问题 In MSVC, DebugBreak() or __debugbreak cause a debugger to break. On x86 it is equivalent to writing "_asm int 3", on x64 it is something different. When compiling with gcc (or any other standard compiler) I want to do a break into debugger, too. Is there a platform independent function or intrinsic? I saw the XCode question about that, but it doesn't seem portable enough. Sidenote: I mainly want to implement ASSERT with that, and I understand I can use assert() for that, but I also want to

Xcode equivalent of ' __asm int 3 / DebugBreak() / Halt?

由 落爺英雄遲暮 提交于 2019-12-17 18:33:09
问题 What's the instruction to cause a hard-break in Xcode? For example under Visual Studio I could do '_asm int 3' or 'DebugBreak()'. Under some GCC implementations it's asm("break 0") or asm("trap"). I've tried various combos under Xcode without any luck. (inline assembler works fine so it's not a syntax issue). For reference this is for an assert macro. I don't want to use the definitions in assert.h both for portability, and because they appear to do an abort() in the version XCode provides.

Behavior of DebugBreak differs between unmanaged and mixed (unmanaged+managed) application?

由 限于喜欢 提交于 2019-12-11 07:32:33
问题 Take the following simple source (name it test.cpp): #include <windows.h> void main() { DebugBreak(); } Compile and link this using the following commands: cl /MD /c test.cpp link /debug test.obj If TEST.EXE is now run (on a 64-bit Windows 7 system), you get the following dialog: Now add the following source file (name it test2.cpp): void hello() { } And compile and link this together with the first source, like this: cl /MD /c test.cpp cl /MD /c /clr test2.cpp link test.obj test2.obj Notice

What is the best way to attach a debugger to a process in VC++ at just the right point in time?

由 徘徊边缘 提交于 2019-12-09 16:09:08
问题 When debugging, sometimes you need to attach an already running process instead of just starting the application in a debugger. It's common for myself to put in a Sleep() or MessageBox call, so that it's easier to attach a debugger. I worry that some of these may be committed eventually to source control. What is the best thing to do to avoid this situation while still delaying enough time so that you can attach your debugger to a running process? Guarding the Sleep or message box with an

How to install a DebugBreak handler?

由 谁说我不能喝 提交于 2019-12-06 11:35:59
问题 We are setting up Appveyor for our Visual Studio solution, which produces a C++ library. A few of our tests [dumb] fuzz C++ objects to ensure they don't do something unexpected. Under debug builds it causes an assert to fire (and in release builds it just throws). We use a custom assert to avoid Posix behavior of crashing a program being debugged. It is shown below. It appears Appveyor or the Operating System kills the program if an assert fires and a debugger is not attached: We want to

How to handle V8 engine crash when process runs out of memory

由 左心房为你撑大大i 提交于 2019-12-05 20:48:28
问题 Both node console and Qt5's V8-based QJSEngine can be crashed by the following code: a = []; for (;;) { a.push("hello"); } node's output before crash: FATAL ERROR: JS Allocation failed - process out of memory QJSEngine 's output before crash: # # Fatal error in JS # Allocation failed - process out of memory # If I run my QJSEngine test app (see below) under a debugger, it shows a v8::internal::OS::DebugBreak call inside V8 code. If I wrap the code calling QJSEngine::evaluate into __try-_

How to install a DebugBreak handler?

由 让人想犯罪 __ 提交于 2019-12-04 16:04:43
We are setting up Appveyor for our Visual Studio solution, which produces a C++ library. A few of our tests [dumb] fuzz C++ objects to ensure they don't do something unexpected. Under debug builds it causes an assert to fire (and in release builds it just throws). We use a custom assert to avoid Posix behavior of crashing a program being debugged. It is shown below. It appears Appveyor or the Operating System kills the program if an assert fires and a debugger is not attached: We want to install a DebugBreak handler if a debugger is not present. This should confirm its the OS doing the killing

How to handle V8 engine crash when process runs out of memory

由 一曲冷凌霜 提交于 2019-12-04 03:48:59
Both node console and Qt5's V8-based QJSEngine can be crashed by the following code: a = []; for (;;) { a.push("hello"); } node's output before crash: FATAL ERROR: JS Allocation failed - process out of memory QJSEngine 's output before crash: # # Fatal error in JS # Allocation failed - process out of memory # If I run my QJSEngine test app (see below) under a debugger, it shows a v8::internal::OS::DebugBreak call inside V8 code. If I wrap the code calling QJSEngine::evaluate into __try-__except ( SEH ), then the app won't crash, but this solution is Windows-specific. Question: Is there a way

What is the best way to attach a debugger to a process in VC++ at just the right point in time?

由 折月煮酒 提交于 2019-12-04 03:17:39
When debugging, sometimes you need to attach an already running process instead of just starting the application in a debugger. It's common for myself to put in a Sleep() or MessageBox call, so that it's easier to attach a debugger. I worry that some of these may be committed eventually to source control. What is the best thing to do to avoid this situation while still delaying enough time so that you can attach your debugger to a running process? Guarding the Sleep or message box with an #ifdef _DEBUG is one way, but I'm wondering if there is a better way. With a Sleep you also have the
订阅 debugbreak