tor on evbarmv6 (raspberry-pi)

[pinswats]

As there are no 2015Q4 binary packages for evbarmv6hf I compiled Tor (tor-0.2.7.6) natively on my Raspberry (first generation Model-B 256MB) from the 2015Q4-Sources.
When I try to start the service via, for example

# /etc/rc.d/tor (one)start

Just nothing happens and the CPU-usage from tor goes above 90%. I already tried waiting for hours, turning debugging on in the torrc file, compiling from latest CURRENT-sources (although it is the same tor version tor-0.2.7.6) so far without success.
I have no idea how to solve or how to debug this problem from here on.

Thanks in advance

EDIT: Forgot to mention: Tried NetBSD 7.0 release and NetBSD-7 stable without any differences. No problems on NetBSD-7 amd64

[jggimi]

Hello and welcome!

Originally Posted by pinswats

I have no idea how to solve or how to debug this problem from here on.

Perhaps, since debugging was enabled in your build, you could attach gdb(1) to the process while it is looping, to try and figure out which function(s) it may be looping through. You can also kill(1) or pkill(1) with a SIGABRT signal(7) to produce a core file for post-processing with gdb().

My advice is generic because I have neither NetBSD nor RPi experience, and can't help with anything specific.

[pinswats]

Originally Posted by jggimi

Perhaps, since debugging was enabled in your build, you could attach gdb(1) to the process while it is looping, [...]

I guess I was a bit disambiguous before, by turning on debugging I meant to enable debug messages in tor logfiles. But since there are no tor logmessages at all, i get nothing.

How to enable debugging during building?

make show-options

gives me no such option for tor.

[jggimi]

There are generally three types of debugging:

1. Application debug messages, written into the application by a developer. These may be turned on by various application dependent flags, from things like a "-v" option for "verbose," or by tokens set with the -D compiler flag, used at compiler pre-processing time.
2. Debugging symbols inserted into the compiled object code, for use with a debugger. I mentioned one in my first reply: the GNU debugger, gdb(). With a debugger you can step through the operation at a source code level, or, even at a machine code level. You can set breakpoints, look at variable and structure values, assign new variable values, and watch an application as it runs step by step.
3. OS-specific system call ("syscall") tracing tools.

Your debugging was type 1. I'd thought you meant type 2. To enable type 2 debugging:

• We tell the compiler to enable debugging symbols in the object produced, so that source code file names, source code line numbers, and source code variable names and types are all recorded in the compiled object. This is done with the -g compiler flag.
• We may also tell the compiler to turn off all optimizations. The program will run more slowly, but variable values won't be hidden from a debugger by having been "optimized out" through storing their values in CPU registers, or other shortcuts the compiler may apply. This is done with the -O0 flag. Capital "Oh" for optimization, and zero for none.
• We may also tell the install script that packages and/or installs the final program not to strip symbols from the final executable. Most standard packaging tools will do that with a strip(1) command. My OS doesn't use pkgsrc, we use different tools, and to disable stripping of symbols at install, I set a line in my port Makefile with

  INSTALL_STRIP=

  so that it doesn't run the strip(1) command. I don't need to do this when I run the binary out of the build directory, rather than installing it. You may not need to disable strip(1) if you do not install the binary.

I don't know much about tor, but I know it uses GNU-style configuration tools. You can add C compiler flags and C++ compiler flags with options such as:

CFLAGS+=-g -O0
CXXFLAGS+=-g -O0

when the GNU configure script is run. You may need to quote the options, depending how the script is called. I always use "+=" rather than "=" and place them after other compiler flags, if any. This is because the last -O level used wins. If you place -O0 before the makefile requested -O2, level 2 optimization will be used by the compiler.

[pinswats]

First of all thanks for the extensive and fast answer. It is really helpful since I am now out of my usual Linux/BSD comfort zone . Since I'm no programmer at all I am not sure if debugging even can help me, but I guess it will be worth a try.
For the next debugging step it will likely take some time since I have a lot of reading manpages, trying and compiling (on raspberry, cross-compiling is no options because of perl dependency ) to do.

[jggimi]

The most helpful thing the debugger can do is display the stack trace. You can see them using gdb's backtrace command, shortened to "bt", or its wonderful synonym, "where".

Every time a function gets called, a new stack frame is created, and the calling one gets saved. It contains saved values, such as variables and instruction pointers, so that when the called function returns, the calling one picks up where it left off.

The top of the stack trace is the most recent function called -- it will be frame number 0. And all of the other calls to that point will be in the trace. You don't need to know much about programming to use it to see what functions call what, and the code paths taken by the program. The gdb frame command will let you inspect any of them for variable values, too. And you can go up and down through the frames with the up and down commands.

Your loop will either be looping through multiple functions, or stuck inside a single function. Either way, you should be able to watch it progress. The gdb() "step" command will move a program one line at a time through a program, including any called functions, while the "next" command will treat a function call as if it is a single instruction. Both may be helpful.

See this recent rant from a non-programmer who increased the security of an unreadable, confusing application, primarily by using stack traces from core files.

[pinswats]

I did in the meanwhile build tor on the latest Raspbian distribution on the same Rpi, no problems there. So it is likely a NetBSD/pkgsrc issue. But I "solved" it on NetBSD, or better found a workaround, by using clang.

[jggimi]

A different compiler in your toolchain circumvented the problem? Then the issue is compiler related, whatever it is. Was. You're past it. Congrats!