Interpreter: Crash with empty statement

[ferdymercury]

Check duplicate issues.

• Checked for duplicates

Description

A silly while(1) {;} makes ROOT interpreter crash. It should instead hang or raise an error.

Reproducer

See above

 *** Break *** segmentation violation
===========================================================
There was a crash (kSigSegmentationViolation).
This is the entire stack trace of all threads:
===========================================================
#0  0x00007ff71a91f3ea in __GI___wait4 (pid=2821543, stat_loc=stat_loc
entry=0x7fff9c648558, options=options
entry=0, usage=usage
entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x00007ff71a91f3ab in __GI___waitpid (pid=<optimized out>, stat_loc=stat_loc
entry=0x7fff9c648558, options=options
entry=0) at ./posix/waitpid.c:38
#2  0x00007ff71a885bdb in do_system (line=<optimized out>) at ../sysdeps/posix/system.c:171
#3  0x00007ff71b2293e0 in TUnixSystem::Exec (this=0x55df65b945f0, shellcmd=0x55df671ac390 "/home/user/builds/build-root_src-Desktop-Debug/etc/gdb-backtrace.sh 2821521 1>&2") at /opt/root_src/core/unix/src/TUnixSystem.cxx:2157
#4  0x00007ff71b229d04 in TUnixSystem::StackTrace (this=0x55df65b945f0) at /opt/root_src/core/unix/src/TUnixSystem.cxx:2448
#5  0x00007ff71b22db8b in TUnixSystem::DispatchSignals (this=0x55df65b945f0, sig=kSigSegmentationViolation) at /opt/root_src/core/unix/src/TUnixSystem.cxx:3668
#6  0x00007ff71b224d84 in SigHandler (sig=kSigSegmentationViolation) at /opt/root_src/core/unix/src/TUnixSystem.cxx:410
#7  0x00007ff71b22da89 in sighandler (sig=11) at /opt/root_src/core/unix/src/TUnixSystem.cxx:3639
#8  0x00007ff71b21547e in textinput::TerminalConfigUnix::HandleSignal (this=0x7ff71b40e6e0 <textinput::TerminalConfigUnix::Get()::s>, signum=11) at /opt/root_src/core/textinput/src/textinput/TerminalConfigUnix.cpp:99
#9  0x00007ff71b215170 in (anonymous namespace)::TerminalConfigUnix__handleSignal (signum=11) at /opt/root_src/core/textinput/src/textinput/TerminalConfigUnix.cpp:36
#10 <signal handler called>
#11 0x00007ff71b490000 in ?? ()
#12 0x00007fff9c64b1f0 in ?? ()
#13 0x00007ff70ba9982f in cling::IncrementalExecutor::executeWrapper (this=0x55df65c22c60, function=..., returnValue=0x55df65e941b0) at /opt/root_src/interpreter/cling/lib/Interpreter/IncrementalExecutor.cpp:217

ROOT version

   ------------------------------------------------------------------
  | Welcome to ROOT 6.33.01                        https://root.cern |
  | (c) 1995-2024, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Dec 12 2024, 08:54:25                 |
  | From heads/scatter2@v6-29-01-6595-g643f369c73                    |
  | With g++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0                   |
  | Try '.help'/'.?', '.demo', '.license', '.credits', '.quit'/'.q'  |
   ------------------------------------------------------------------

Installation method

Debug build

Operating system

Ubuntu 22

Additional context

Crash might be happening at similar place than #15537

[dpiparo]

On macOS, with master, root quits without any error with while(true). Arguably not a very useful piece of code to write at the prompt, but still...

[hahnjo]

Note that infinite loops are undefined behavior in C++ and LLVM will exploit this during optimization. As a very simplified explanation, because the loop has no side-effects and C++ guarantees that every statement must terminate, LLVM can just remove it (there is a famous blog post about LLVM "optimizing" an infinite loop, but I can't find it right now). I assume this leads to slightly broken code being emitted, for example that is missing a return instruction? In any case, I would put this very low on the priority list, if it's even worth fixing...

[pcanal]

Relates to llvm/llvm-project#60622

[hahnjo]

Relates to llvm/llvm-project#60622

Yes, that's the code example I was looking for! I though there was a well-written blog post about that somewhere, but might have been wrong...

[ferdymercury]

I assume this leads to slightly broken code being emitted, for example that is missing a return instruction?

Thanks for the explanation. So this is maybe then a duplicate of #15537 and can be closed?

(I still argue that it would be useful to fix this, to not lose your whole ROOT working session if you type something wrong by mistake at the prompt. Low priority of course.)

[hahnjo]

So this is maybe then a duplicate of #15537 and can be closed?

Possible, but unclear. In case of #15537, the input has semantic issues, not just UB at run time...