Readit News logoReadit News
moyix · 3 years ago
Haha, I don't know how folks found this, but I actually did make it for a real-world use case. While doing large-scale builds of debian packages [1], occasionally I'd have parts of the build process hang (usually some test that I didn't care about). I didn't want the whole build to fail, so I needed some way to kill the process but have it return 0 so that make and friends wouldn't think anything was amiss.

Also, credit where credit is due -- the original idea was suggested to me by Kyle Huey: https://twitter.com/moyix/status/1484342467205816325

[1] https://moyix.blogspot.com/2022/02/on-building-30k-debian-pa...

app4soft · 3 years ago
> Haha, I don't know how folks found this

I found it yesterday on Ukrainian Linux users forum[0], and decided to re-post it on HN ;)

[0] https://linux.org.ua/index.php?topic=11868

js2 · 3 years ago
This is using exit_group() (#231), not exit() (#60):

http://main.lv/notes/syscalls.md

https://man7.org/linux/man-pages/man2/exit_group.2.html

> Note: glibc provides no wrapper for exit_group(), necessitating the use of syscall(2).

Hmm, but elsewhere I find:

> In glibc up to version 2.3, the _exit() wrapper function invoked the kernel system call of the same name. Since glibc 2.3, the wrapper function invokes exit_group(2), in order to terminate all of the threads in a process.

https://www.man7.org/linux/man-pages/man2/_exit.2.html

z3c0 · 3 years ago
May not be as portable, but "exit(1)" would probably make it seem more like an accident.
jgtrosh · 3 years ago
That would make it look like suicide and not an accident
dylan604 · 3 years ago
Yeah, but was the suicide done to it?
SnowHill9902 · 3 years ago
Suicided.
iasay · 3 years ago
I see this like a cartoon black hole painted on the ground.
Vogtinator · 3 years ago
Wouldn't just "p exit(0)" do the same, just with gdb doing the heavy lifting?
Hello71 · 3 years ago
not if the program is statically linked and stripped.
Vogtinator · 3 years ago
I'm sure there's a way to do syscalls like that from gdb as well
sph · 3 years ago
What's at 0x050f? Looks like they set the rip register to that value.
tux3 · 3 years ago
That's the syscall instruction (0f 05).

It's not jumping to that address, it's injecting the exit syscall right under the instruction pointer. If you wanted to modify the register, you'd do `set $rip = 0x050f` without the `{short}`

pxeger1 · 3 years ago
So would this not work if the program's code is mapped read-only?
josephcsible · 3 years ago
They're not changing the rip register at all. They're setting the contents of the memory location pointed to by the rip register to 0x050f. The equivalent of "set {x}y = z" in C would be "*(x *)y = z;".

Deleted Comment

Sebb767 · 3 years ago
Wouldn't this technically be a suicide? The process calls exit itself, after all.
EUROCARE · 3 years ago
The kind of suicide where you fall on a knife, several times...
formerkrogemp · 3 years ago
Accidental discharge of gun is a frequent cause of death in the wild, wild united states of guns. Why not also falling out of window, tripping in kitchen with knife, or eating poorly cooked meat, comrade?
WJW · 3 years ago
Nono, it calls `exit(0)` only once. :)

(I love the cell block tango)

iso1631 · 3 years ago
It had it coming
OJFord · 3 years ago
Involuntary assisted suicide, I suppose!
dylan604 · 3 years ago
Maybe it should call \x0988 for advice first?
Godel_unicode · 3 years ago
Call not connected, foiled again by hex…
tomas789 · 3 years ago
To be honest I was expecting different kind of content.