Program which behaves differently in/out of a debugger [closed]

Question

The challenge is to write a deterministic program (any language/OS) which takes no arguments or other input and behaves differently in a debugger from how it behaves when not being debugged.

For example, the program may output something when being debugged but not output anything when not being debugged. Or output something different in each case. Or it may crash when being debugged but not crash when not being debugged. Or vice-versa.

Caveats and clarifications:

• Timing differences do not count.
• Interpreted languages are permitted.
• To emphasize determinism: the behaviour must be exactly reproducible both in and out of debugging context.
• The presence of the debugger itself should the only difference between the two cases.
  • Telling the debugger to add inputs (stdin or argv ENV or whatever) is cheating, the debugger should run the program "as-is".
  • Changing the environment (e.g. running in a virtual machine or different OS, or changing OS settings such as memory limits) between debug and non-debug runs is not permitted.

Shortest code wins. I may award a bounty which reveals something interesting about how debuggers work.

Answer 1

x86 and x64_64 machine language on Linux and OSX, 1 byte

0x0:  CC    int3 

Try it online!

int 3 throws a SIGTRAP which will cause a debugger to stop as if it encountered a breakpoint. Outside of a debugger, the kernel terminates the process (thanks to @Ruslan for the correction).

C (gcc) (x86 Linux and OSX), 14 11 9 bytes

main=204;

Try it online!

The integer 204 corresponds to the int 3 instruction; the TIO link is the same as above.

Answer 2

APL (Dyalog Unicode), 0 bytes

In Dyalog APL, debugger vs no debugger is choosen by running one's workspace in either the IDE interpreter or the runtime interpreter.

Loading a completely empty default settings workspace into the IDE interpreter, immediately drops the user into REPL mode as applications must actively shut down the interpreter for it to quit:

However, the runtime interpreter does not have a REPL mode, and so if an application comes to an end (for example because it is completely empty) and does not explicitly shut down the interpreter, it implicitly has attempted to reach REPL mode ("the APL session"), and complains:

Answer 3

JavaScript on Firefox, 69 bytes

WARNING: This script may hang your browser! Do NOT test it with other browsers (e.g. Chrome) as it may crash your tab / browser.

for(console.log(a={},i=99);--i;a=a.a={k:new Int8Array(1e9)});alert(1)

How: When debugger is enabled with console tab activated. console.log makes memory leak possible, and the program will run out of memory soon. When debugger is disabled, GC would clear memory allocated, and you would see an alert with text 1 finally.

Answer 4

MSVC (64-bit), 50 35 bytes

main(){return IsDebuggerPresent();}

Exits with code 0 normally but 1 under the debugger (note that WinDbg does not automatically display the exit code but you can fake it by examining the stack). Edit: Saved 15 bytes thanks to @Ruslan.

Answer 5

T-SQL, 6 bytes

sp_who

Always returns an extra row under the executing user's name when the debugger is active.

Answer 6

Python, 29 bytes

import sys
sys.modules['pdb']

Without debugger (python3 /tmp/foo.py):

Traceback (most recent call last):
  File "/tmp/foo.py", line 2, in <module>
    sys.modules['pdb']
KeyError: 'pdb'

With debugger (python3 -m pdb /tmp/foo.py):

(empty output)

because pdb is loaded into an app-visible module in the second case.

Answer 7

JavaScript, 17 bytes

debugger
alert(1)

debugger stops execution if the debugger console is open, else it does nothing

Answer 8

Java, 131 102 100 bytes

v->(java.lang.management.ManagementFactory.getRuntimeMXBean().getInputArguments()+"").split(":jdwp")

When running without a debugger this function returns an array of length 1. When running with a debugger, this returns an array of length 2 (greater than 1).

Try it online!

This technically detects if you could attach a debugger; not if one is currently connected... Not sure if that's valid

-23 bytes thanks to Olivier Grégoire for mentioning that I can cut down on what I search for in the runtime parameters and for lambda-izing my answer

-5 bytes thanks to Benjamin Urquhart for noting that calling toString is dumb when I can let Java implicitly convert

-2 bytes thanks to Benjamin Urquhart for changing the return type

Answer 9

Robotalk, 22 bytes

debug l: chronon l ifg

If the debugger is active, the debug instruction pauses execution until the end of the current game tick. In this case, the variable "chronon" is always 1 or greater when read, and the program executes an infinite loop. If the debugger isn't active, debug is a one-cycle no-op. "Chronon" is now 0 when read, the "ifg" branch isn't taken, and execution reaches the end of the code, which is an error condition.

Answer 10

MATLAB, 6 bytes

dbquit

When stopped in the debugger, this will quit debugging mode.

When not under debug, it will print an error message that it cannot be used when not stopped in the debugger.

It should be noted this only works for evaluation in the command window (one of the three ways of running MATLAB code). It won't work in a function or script as once you try to run the script or function, you stop being in debug mode during execution.

The closest you can get to something that will run in a function/script as well would be:

MATLAB, 22 bytes

feature('IsDebugMode')

This is an undocumented command in MATLAB. If you are stopped in the debugger in a script or function, and then call another function (or command evaluation) that contains the above line, it will return true.

Outside the debugger it will return false.

If you were however to just run a script/function containing the above, even if you add a breakpoint at the start of the script/function and step through, it will return false, because again, once you start executing you stop being in the debugger temporarily.