ios Symbolication Server side - objective-c

How to symbolicate the ios crash report after uploading to server in a linux environment where iOS development tools and scripts will not be available. I know Apple uses atos and some other tools to map the hex addresses to symbol along with .dYSM file.
I can upload .dYSM file along with crash report to server. Refered QuincyKit, but they are doing symbolication locally. But other's like HockeyApp and Critterism are doing it remotely.
Pls recommend the possible ways to do it in server.

It is possible. You can take a look at https://github.com/facebook/atosl
I got it working under Linux. (Ubuntu Server) However, it takes some time to get it up and running.
Installing atosl
First, you need to install libdwarf-dev, dwarfdump, binutils-dev and libiberty-dev.
E.g. on Ubuntu:
$ sudo apt-get install libdwarf-dev dwarfdump binutils-dev libiberty-dev
Download or clone the atosl repo from GitHub:
$ git clone https://github.com/facebook/atosl.git
CD to the atosl dir
$ cd atosl
Create a local config config.mk.local which contains a flag with the location of your binutil apps. (in Ubuntu by default that's /usr/bin). If you're not sure, you can find out by executing cat /var/lib/dpkg/info/binutils.list | less and copy the path of the file objdump. E.g. if the entry is /usr/bin/objdump, your path is /usr/bin.
So in the end, your config.mk.local should look like this:
LDFLAGS += -L/usr/bin
Compile it:
$ make
Now you can start using it:
$ ./atosl --help
Symbolicating example
To show how atosl is used, I'll provide a simple example.
Now let's take a look at a line from the crash log:
13 ErrorApp 0x000ea294 0xe3000 + 29332
To symbolicate this, we will need the load address, and the runtime address.
In this example the runtime address is 0x000ea294, and the load address is 0xe3000.
Now we have everything we need:
$ ./atosl -o [YOUR_dSYM_FILE] -l [LOAD_ADDRESS] [RUNTIME_ADDRESS]
In this example:
$ ./atosl -o ErrorApp.app.dSYM/Contents/Resources/DWARF/ErrorApp -l 0xe3000 0x000ea294
Which returns the symbolicated line:
main (in ErrorApp) (main.m:16)
FYI
Your vmaddr, which usually is 0x00001000, you can find by looking at the segname __TEXT Mach-O load command of your binary. In my example, this happens to be different, namely 0x00004000
To find the address, we need to do some math.
The address is found by the following formula:
address = vmaddr + ( runtime_address - load_address )
In this example our address is:
0x00004000 + ( 0x000ea294 - 0xe3000 ) = 0xB294
I haven't played around with this that much yet, but for now it seems to give me the results I needed. Maybe it will work for you too.

You need to implement your own linux compatible versions of atos, otool and dwarfdump (at least the functionality needed for symbolication). The Apple tools are not open source and only run on Mac OS X.
None of the services provide a solution that can be used by 3rd parties on non OS X systems. So your only chance, besides implementing the required functionality to run on your linux system, is to do it on a Mac like QuincyKit does it, see https://github.com/TheRealKerni/QuincyKit/wiki/Remote-symbolication or use a third party service.
Note: I am the creator of QuincyKit and Co-Founder of HockeyApp.

Related

Building a kernel module on Centos 7 with a CMake file

Sorry for the length. I have tried to include as much information as possible.
A device I work with randomly fails to start at boot - this is a well known issue with the device and there are lots of posts on the web with no known solution except reboot.
So the task is to look in dmesg for a certain string that if present means the device has failed to start and the system needs rebooting. A simple call to system() with boot seems to do the job.
A unit test that proves this would be nice. The idea is to look for a non-existant uuid in the dmesg log to prove that it fails to find one and then to write a different uuid to the log and then search for that. Proving it works in both cases.
First thing was to hit up google: Find you can write to the kernel log with # echo '<4>Foo: Message' | sudo tee /dev/kmsg which works from terminal but the sudo may cause issue in the unit test.
The next thing I looked at was accessing it via code. The unit tests are written in C++ and the library is googletest.
Most posts talk about writing a Makefile and kbuild. I am working in a build system where we have cmake called from a shell script.
After several hours of searching and trying things, I decided to ask here.
I have installed
kernel.x86_64 3.10.0-1062.el7 #anaconda
kernel.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-devel.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-devel.x86_64 3.10.0-1160.24.1.el7 #updates
kernel-headers.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-tools.x86_64 3.10.0-1160.21.1.el7 #updates
kernel-tools-libs.x86_64 3.10.0-1160.21.1.el7
uname -r gives 3.10.0-1160.21.1.el7.x86_64 which seems to suggest I have the kernel headers and devel files installed.
Doing a find /. -name module.h lists:
...
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/arch/x86/include/asm/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/asm-generic/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/linux/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/trace/events/module.h
/usr/src/kernels/3.10.0-1160.24.1.el7.x86_64/include/uapi/linux/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/arch/x86/include/asm/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/asm-generic/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/trace/events/module.h
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/uapi/linux/module.h
...
It maybe that I am trying to link files in /3.10.0-1160.24.1.el7.x86_64/ when I should be linking to 3.10.0-1160.21.1.el7.x86_64/. Listing installed yum packages via sudo yum list | grep linux-d returns
libselinux-devel.x86_64 2.5-15.el7 #base
libhbalinux-devel.i686 1.0.17-2.el7 base
libhbalinux-devel.x86_64 1.0.17-2.el7 base
libselinux-devel.i686 2.5-15.el7 base
syslinux-devel.x86_64 4.05-15.el7 base
My CMakeFiles.txt looks like
project( X_test )
set( TEST_SOURCE
X_test.cpp
)
execute_process(COMMAND uname -r OUTPUT_VARIABLE uname_r OUTPUT_STRIP_TRAILING_WHITESPACE)
include_directories(/usr/src/kernels/${uname_r}/include)
link_directories(/lib/modules/${uname_r}/build)
add_library(source-lib STATIC source.c)
Anything else in there has been commented out to prevent confusion.
Without the lines include_directories or link_directories I get the error
#include <linux/module.h>
With those lines in I get the error:
In file included from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/kernel.h:6:0,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/cache.h:4,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/time.h:4,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/stat.h:18,
from /usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/module.h:10,
from /home/user/git/asdo/Services/DCO-3303/test/source.c:1:
/usr/src/kernels/3.10.0-1160.21.1.el7.x86_64/include/linux/linkage.h:7:25: fatal error: asm/linkage.h: No such file or directory
#include <asm/linkage.h>
The code I am compiling is the standard printk(KERN_INFO "Hello world\n"); which you can see here.
How do I go about compiling code that uses a kernel call through CMake?

MSP430 toolchain in linux

Can anybody please guide procedure to setup tool-chain for MSP430 in Linux (particularly Ubuntu) ? I am using MSP430 launchpad (MSP-EXP430G2), and I need to setup compiler/build tools and debugger drivers.
If you install Texas Instruments' CCS IDE, Linux version, it will install the tool-chain. There are, however, other problems in developing for MSP430 in Linux. The bugs and fixes are detailed in my post here:
MSP430 / eZ430-RF2500 Linux support Guide
"Compile code using Code Composer Studio (CCS)
Download CCS for Linux.
Create a new CCS project with a Custom MSP430 Device or any other.
Compile the code. The result binary image will be in the workspace. The workspace path can be found in “File” / “Switch workspace”.
The file that should be programmed to the device is the project-name.out file.
Program and run device using mspdebug
Download and Install mspdebug
From the directory with the file project-name.out run:
$ sudo mspdebug rf2500
Now you are in mspdebug’s command line shell. Run the following to program and run the device:
(mspdebug) prog project-name.out
(mspdebug) run
Use Ctrl+c to pause run and get command line back.
Fix a Linux Kernel bug that prevents Minicom to communicate with device
The device path in /dev is /dev/ttyACM0. Currently, connecting to it
serially using utilities such as minicom is not possible, and you get the message “/dev/ttyACM0: No such file or directory”.
The bug is in Kernel module “cdc_acm”. The solution is to fix the bug in the source code, recompile the module and plug it instead of the existing one.
Find out Linux version:
$ uname -r
cdc_acm’s source is the files cdc-acm.c and cdc-acm.h. They are under the Linux path drivers/usb/class/.
Download these two files from a repository that matches your Linux version. Such repos are available in lxr.free-electrons.com and www.kernel.org.
Create a new directory and move the files to it.There are two code segments need to be removed or commented out:
The next lines appear in function “acm_port_activate()” on newer versions and in “acm_tty_open()” in older ones:
// if (0 > acm_set_control(acm, acm->ctrlout = ACM_CTRL_DTR | ACM_CTRL_RTS) &&
// (acm->ctrl_caps & USB_CDC_CAP_LINE))
// goto bail_out;
The next line appears in function “acm_port_shutdown()” on newer versions “acm_port_down()” in older ones:
// acm_set_control(acm, acm->ctrlout = 0);
Create a Makefile and compile:
$ echo 'obj-m += cdc-acm.o' > Makefile
$ make -C /lib/modules/`uname -r`/build M=$PWD modules
You should have a new cdc-acm.ko file in the directory
Replace the existing module (This change will be discarded after boot):
$ sudo rmmod cdc-acm
$ sudo insmod ./cdc-acm.ko
Communicate via the serial port using Minicom
Launch minicom setup from command line:
$ minicom -s
In the menu, choose:
Serial port setup
Press ‘A’ (for “Serial Device”).
Replace Current device path with:
/dev/ttyACM0
Press ‘E’ (for “Bps/Par/Bits”).
Set the correct data rate for your device.To lower the rate (to 1200, for instance), keep pressing ‘B’ (for “previous”) until the top line shows:
Current: 1200 8N1
Press “Enter” until returning to main menu, there, press “Exit”.This will exit the setup menu and start running on the device. From now on you should see messages over the serial connection: It is up to you to program the device with such messages."
Download the pre-compile tool-chain (.run file) form http://www.ti.com/tool/msp430-gcc-opensource
Unzip
Execute chmod +x <downloaded file>
Run the installer
enjoy!

Xcode distributed build failure

I am trying to do distributed builds with Xcode, but I see this error while building from my build server (Build Sever is the host, dev machine is the client).
When I try to do this the other way, I am able to distribute builds (My Dev machine as the host and the Build Sever as the client)
Any thoughts?
[14:44:47]: Step 2/3 (6m:10s)
[14:44:57]: [Step 2/3] distcc[95606] (dcc_parse_multiplier) ERROR: bad multiplier "/0,lzo,cpp" in host specification
[14:44:57]: [Step 2/3] distcc[95606] (dcc_show_hosts) CRITICAL! Failed to get host list
[14:44:57]: [Step 2/3] /usr/bin/pump: error: pump mode requested, but distcc hosts list does not contain any hosts with ',cpp' option
Your milage may vary with this solution, but we've had to hack the distcc that comes with Xcode to force pump mode to be off to fix this problem.
Remove pump from /Developer/usr/bin and /usr/bin, just write out an empty file named pump in its place
Don't forget to chmod a+x your pump and distcc (in the next step)
In /Developer/usr/bin, rename distcc to distcc.bin and write out this distcc
#!/bin/bash
hosts=$DISTCC_HOSTS
hosts=${hosts//\,cpp/}
export DISTCC_HOSTS=$hosts
echo Modified DISTCC_HOSTS=\"$DISTCC_HOSTS\"
/Developer/usr/bin/distcc.bin $#
Apologies, this is a quick and dirty solution. There is probably a cleaner way to do this.
Please restart the build server and your own computer. That usually does the trick for me, also, update to the latest xcode 4

Debugging Solaris OS crash

I have access to a remote Solaris terminal which crashes occasionally, and I have to ask someone with physical access to boot the machine up, which it does successfully. I would like to know which tools/files should I look at to find out the cause of the crash so that I can make the necessary configuration changes and avoid it in the future.
What tools you can use will depend on what version of solaris you have running and what the actual problem
is. The first thing to do is check the system console (which it sounds like you don't have access to) and the /var/adm/messages file. This file is updated with system messages and the newest will appear at the end.
Next, you can look for a system core file. If a core file is created, it would be in /var/crash/hostname where "hostname" is the name of the machine.
If you have an actual core file in the /var/crash/hostname directory, this set of commands will give you a good
string to search google with:
# cd /var/crash/hostname
Replace "hostname" with the hostname of your machine.
# mdb -k unix.0 vmcore.0
If you have multiple core files, select the most recent version.
> ::status
This should give you a panic message, cut and paste that into google and see what you can find.
For more core file analysis read this:
http://cuddletech.com/blog/pivot/entry.php?id=965

How detect whether running under valgrind in make file or shell script?

I need to detect whether my Makefile is running under valgrind (indirectly, using valgrind --trace-children=yes), I know how to do it from C but I have not found a way to do it from a script,
The earlier answers works on Linux only. For Mac OS X I am an going to grep for VALGRIND_STARTUP_PWD in the environment, unless someone has a better idea.
from a shell:
grep -q '/valgrind' /proc/$$/maps && echo "valgrindage"
This determines if the valgrind preloaded libraries are present in address map of the process. This is reasonably effective, but if you happen to have a non-valgrind related library that shares the '/valgrind' moniker then you will get a false positive (unlikely).
[I changed the grep pattern from vg_preload to /valgrind, as testing on Debian/Ubuntu revealed that the library name was different, while a directory match of valgrind is most likely to succeed.]