After compiling proxychains-ng with Apple Silicon --fat-binary-m1 support on macOS 12 (M1 Max), I'm finding that the binary is immediately terminated by the operating system. Intuition pushed me towards thinking there's some kind of a permission problem, but I've been unable to isolate such a problem so far. Even when running lldb it doesn't even get to an initial breakpoint.
I'll share the pertinent shell results in macOS that lead me to this point in hoping that someone might have seen something similar or may know what's going on:
$ git clone https://github.com/rofl0r/proxychains-ng.git
$ cd proxychains-ng
$ CFLAGS="-g3 -O0" ./configure --fat-binary-m1 --sysconfdir=/opt/homebrew/etc/
...
$ make
$ ./proxychains4
fish: Job 1, './proxychains4' terminated by signal SIGKILL (Forced quit)
$ ./proxychains4 ping 1.1.1.1
fish: Job 1, './proxychains4 ping 1.1.1.1' terminated by signal SIGKILL (Forced quit)
$ lldb proxychains4 ping 1.1.1.1
(lldb) target create "proxychains4"
Current executable set to '~/src/proxychains-ng/proxychains4' (arm64e).
(lldb) settings set -- target.run-args "ping" "1.1.1.1"
(lldb) b main
Breakpoint 1: where = proxychains4`main + 60 at main.c:69:8, address = 0x0000000100003578
(lldb) run
error: process exited with status -1 (no such process.)
For good measure I've verified that SIP and Gatekeeper are off:
$ csrutil status
System Integrity Protection status: disabled.
$ spctl --status
assessments disabled
In attempting to dig a bit deeper to see if there's a system call that's triggering the kill, I can't seem to get anywhere. ktrace and dtruss just aren't getting me anywhere.
Any thoughts on what's going on here?
I think I know what is going on. You have built a Universal binary including an arm64e slice. Since the arm64e ABI is not yet stable, only system binaries can use the arm64e ABI. In terminal, the system just ignores the arm64e slice, since it isn't allowed to run, and runs the arm64 one instead. But lldb isn't as restrictive, and tries to run the arm64e slice, and that fails. You can fix this either by not building the arm64e slice (which isn't going to run anyway). Or you can do target create -arch arm64 proxychains4 to tell lldb to run the arm64 slice.
Related
I am trying to learn Hugo using a Go debugger called dlv. And I am pretty stuck. After:
go get -v github.com/gohugoio/hugo
cd $GOPATH/src/github.com/gohugoio/hugo
go build -gcflags="-N -l"
dlv exec ./hugo -- -s /path/to/the/projectdir
This hangs. Pressing Ctrl+C runs hugo as normal. As far as I can see dlv debug not only produces the same behavior but it's the exact same: the produced binary called debug is the exact same as the hugo I built with go build -gcflags="-N -l".
dlv launches a number of child processes, these disappear after a while. The hugo process is visible via ps and pidof hugo but strace -ppidof hugo`` reports strace: attach: ptrace(PTRACE_ATTACH, ...): No such proce. Checking after, it's still in the ps list, the same pid. I would guess because it's in t state as it is being traced.
How could I then watch Hugo running?
Aaaaand it's Linux subsystem for Windows! I never thought that'd make a difference but following Jonah B's answer " I am on fedora" I tried it on a Debian box and it worked. I am surprised because strace works fine on WSL (actually the github instructions on filing a report includes strace). I filed this bug.
Hmm, doesn't happen for me. dlv prompt appears right away. I am on fedora, have been using hugo regularly over the past week or so.
$ dlv exec ./hugo -- --cleanDestinationDir -s /path/to/blog/root/
Type 'help' for list of commands.
(dlv) c
| EN
+------------------+----+
Pages | 25
Paginator pages | 0
Non-page files | 0
Static files | 11
Processed images | 0
Aliases | 0
Sitemaps | 1
Cleaned | 0
Total in 46 ms
Process 41032 has exited with status 0
$
Same experience here. However it doesn't hang, it just takes a significant time to reach the dlv prompt.
Check the usage of your memory (for instance with mpstat or vmstat if you are on Linux). I have 16G main mem and 16G of swap. Until the dlv prompt is reached, nearly all my memory and a significant amount of swap is consumed. During the startup time any playing video or music stutters and the PC is practically unusable until dlv is ready.
Hugo is pretty large app in that respect.
On a i686 / 32-bit dual CPU, with a fresh Debian Stretch installation, I've installed Octave 4.2.1 and run ./mytest after providing it with execution privileges:
#!/bin/bash
./mytest.m
where test.m reads
#!/usr/bin/octave
exit(0)
The result is:
Terminate called after throwing an instance of 'octave::exit_exception'
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'..
save to 'octave-workspace' complete
octave exited with signal 6
but the program is intended to exit normally. Same result replacing exit with quit, but it terminates correctly when starting it with $ octave -q --no-gui and then > quit. What's wrong here?
Update: In the meanwhile, this showed up: http://savannah.gnu.org/bugs/?49271, so now the question would be: can a non-Octave configuration solve the problem? (Confirmed: Octave 4.0.0 does not reproduce the error.)
I am trying to debug GDB itself and dealing with a Ctrl+C signal problem that is sent from another terminal.
I run GDB to be debugged in terminal 1 in TUI mode. Right after, I open another terminal 2 and find the PID number of the GDB that runs on Terminal 1. Then attach that process to debug.
In Terminal 1
$ build-gdb/gdb/gdb -tui ./build/output.elf -tty=$TTY
In Terminal 2
$ ps -elf | less
$ sudo gdb -p PID_NUMBER-tty=$TTY -tui
The problem is when I hit Ctrl+C to stop GDB in terminal 1, GDB runs on Terminal 2 stops. GDB in Terminal 1 does not responds to ^C command at all. I tried to use -tty parameter and get the current TTY, but id did not solved the problem. GDB uses readline GNU library, but i should be configure terminal and its input properly.
Any idea?
You can use
handle SIGINT pass
to instruct GDB to pass the signal to the inferior. See Signals in the GDB manual. The nostop argument could be useful in this situation, too.
I'm trying to run binaries built with clang's address sanitizer under the control of ptrace, and I'm having a problem with spurious SIGTRAPs.
My program uses ptrace in the standard manner: child does ptrace(PT_TRACE_ME,...) then exec; parent waits for SIGTRAP in child that indicates the call to exec was made; parent does ptrace(PT_CONTINUE,...) to set the child running.
This all works fine for normal binaries. When running a binary built with the address sanitizer, on the other hand, after doing the PT_CONTINUE to resume the process, the child process receives an unexpected SIGTRAP straight away.
This can be demonstrated using gdb, which interacts with ptrace in a similar sort of way.
Build a simple test program:
$ echo 'int main(){return 50;}' | clang -fsanitize=address -o test -xc -
$ ./test
$ echo $?
50
Run it in gdb:
$ ggdb ./test
<<snip>>
(gdb) run
(Ignore messages about symbols.)
Note that the process has not exited with code 062, but has stopped with a SIGTRAP:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007fff5fc01000 in ?? ()
To run the process, continue it manually.
(gdb) continue
Continuing.
[Inferior 1 (process 14536) exited with code 062]
This is all very well for interactive use, but it's a bit tiresome for automated tests, because you need special handling for the address sanitizer builds. I'd much rather keep my test processes the same across all build types if possible.
Anybody know what is going on here?
I'm using clang-700.1.76 (from Xcode). (And gdb 7.9.1 (from MacPorts) - but this looks like a more general problem as my own code suffers from it too.)
I couldn't reproduce this in Linux (gcc 4.8.4/clang 3.8.0, gdb 7.7.1).
I am trying to debug a concurrent program in LLDB and am getting a seg fault, but not on every execution. I would like to run my process over and over until it hits a seg fault. So far, I have the following:
b exit
breakpoint com add 1
Enter your debugger command(s). Type 'DONE' to end.
> run
> DONE
The part that I find annoying, is that when I get to the exit function and hit my breakpoint, when the run command gets executed, I get the following prompt from LLDB:
There is a running process, kill it and restart?: [Y/n]
I would like to automatically restart the process, without having to manually enter Y each time. Anyone know how to do this?
You could kill the previous instance by hand with kill - which doesn't prompt - then the run command won't prompt either.
Or:
(lldb) settings set auto-confirm 1
will give the default (capitalized) answer to all lldb queries.
Or if you have Xcode 6.x (or current TOT svn lldb) you could use the lldb driver's batch mode:
$ lldb --help
...
-b
--batch
Tells the debugger to running the commands from -s, -S, -o & -O,
and then quit. However if any run command stopped due to a signal
or crash, the debugger will return to the interactive prompt at the
place of the crash.
So for instance, you could script this in the shell, running:
lldb -b -o run
in a loop, and this will stop if the run ends in a crash rather than a normal exit. In some circumstances this might be easier to do.