When using lldb to debug a program, the program crashes and I print "bt" to backtrace. But even I scroll all the way back to the top of the screen, I still don't see the where the program is crashed because the backtrace is too large.
If you're using Terminal.app on Mac OS X, you can increase the size of your scroll-back buffer by opening the Preferences window for Terminal, click on the Profiles tab, there will be a series of buttons on the right, "Text / Window / Shell / Keyboard / Advanced". Under "Window" under "Scrollback" you can select a number of rows, or whether Terminal should limit the scrollback buffer to a number of lines.
Also, in lldb, the bt command accepts an argument which is the number of stack frames to show. It sounds like it's the first few stack frames that you're having trouble seeing, so this is exactly what you want. For instance, here I have bt only showing me the first two stack frames:
(lldb) bt
* thread #1: tid = 0x09bd, 0x00007fff888194de libsystem_kernel.dylib`mach_msg_trap + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* #0: 0x00007fff888194de libsystem_kernel.dylib`mach_msg_trap + 10
#1: 0x00007fff8881864f libsystem_kernel.dylib`mach_msg + 55
#2: 0x00007fff85c75b34 CoreFoundation`__CFRunLoopServiceMachPort + 212
#3: 0x00007fff85c74ffb CoreFoundation`__CFRunLoopRun + 1371
#4: 0x00007fff85c74858 CoreFoundation`CFRunLoopRunSpecific + 296
#5: 0x000000010148f497 Dock`___lldb_unnamed_function2$$Dock + 1202
#6: 0x00007fff8e7fd5c9 libdyld.dylib`start + 1
#7: 0x00007fff8e7fd5c9 libdyld.dylib`start + 1
(lldb) bt 2
* thread #1: tid = 0x09bd, 0x00007fff888194de libsystem_kernel.dylib`mach_msg_trap + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
* #0: 0x00007fff888194de libsystem_kernel.dylib`mach_msg_trap + 10
#1: 0x00007fff8881864f libsystem_kernel.dylib`mach_msg + 55
(lldb)
Related
After looking through the logs of a recent test flight my craft reported a value of 4 for the variable fix_type of class dronekit.GPSInfo(eph, epv, fix_type, satellites_visible).
eph and epv had no value and satellites_visible varied between 9 and 12.
The flight was 30 minutes long. The GPS module is ublox gps + compass module.
Indoors I get fix_type 0 or 1 as expected, but out doors I get 3-4? I can find info on a 3D fix, but what does a 4D GPS fix mean?
How is this variable getting set in the source code?
class GPSInfo(object):
"""
Standard information about GPS.
If there is no GPS lock the parameters are set to ``None``.
:param Int eph: GPS horizontal dilution of position (HDOP).
:param Int epv: GPS vertical dilution of position (VDOP).
:param Int fix_type: 0-1: no fix, 2: 2D fix, 3: 3D fix
:param Int satellites_visible: Number of satellites visible.
.. todo:: FIXME: GPSInfo class - possibly normalize eph/epv? report fix type as string?
"""
def __init__(self, eph, epv, fix_type, satellites_visible):
self.eph = eph
self.epv = epv
self.fix_type = fix_type
self.satellites_visible = satellites_visible
def __str__(self):
return "GPSInfo:fix=%s,num_sat=%s" % (self.fix_type, self.satellites_visible)
Other UBLOX GPS code struct gpsData defines fix type as having the following values:
GNSSfix Type:
0: no fix
1: dead reckoning only
2: 2D-fix
3: 3D-fix
4: GNSS + dead reckoning combined,
5: time only fix
So the values 4 and 5 likely do not mean 4D and 5D fixes as you assume given the values for 2 and 3, and make sense given the scenario you describe.
I'm unable to write 1514 bytes (including the L2 information) via write to /dev/bpf. I can write smaller packets (meaning I think the basic setup is correct), but I see "Message too long" with the full-length packets. This is on Solaris 11.2.
It's as though the write is treating this as the write of an IP packet.
Per the specs, there 1500 bytes for the IP portion, 14 for the L2 headers (18 if tagging), and 4 bytes for the checksum.
I've set the feature that I thought would prevent the OS from adding its own layer 2 information (yes, I also find it odd that a 1 disables it; pseudo code below):
int hdr_complete = 1;
ioctl(bpf, BIOCSHDRCMPLT, &hdr_complete);
The packets are never larger than 1514 bytes (they're captured via a port span and start with the source and destination MAC addresses; I'm effectively replaying them).
I'm sure I'm missing something basic here, but I'm hitting a dead end. Any pointers would be much appreciated!
Partial Answer: This link was very helpful.
Update 3/20/2017
Code works on Mac OS X, but on Solaris results in repeated "Interrupted system call" (EINTR). I'm starting to read scary things about having to implement signal handling, which I'd rather not do...
Sample code on GitHub based on various code I've found via Google. On most systems you have to run this with root privileges unless you've granted "net_rawaccess" to the user.
Still trying to figure out the EINTR issue. Output from truss:
27158/1: 0.0122 0.0000 write(3, 0x08081DD0, 1514) Err#4 EINTR
27158/1: \0 >E1C09B92 4159E01C694\b\0 E\005DC82E1 #\0 #06F8 xC0A81C\fC0A8
27158/1: 1C eC8EF14 Q nB0BC 4 V #FBDE8010FFFF8313\0\00101\b\n ^F3 W # C E
27158/1: d SDD G14EDEB ~ t sCFADC6 qE3C3B7 ,D9D51D VB0DFB0\b96C4B8EC1C90
27158/1: 12F9D7 &E6C2A4 Z 6 t\bFCE5EBBF9C1798 r 4EF "139F +A9 cE3957F tA7
27158/1: x KCD _0E qB9 DE5C1 #CAACFF gC398D9F787FB\n & &B389\n H\t ~EF81
27158/1: C9BCE0D7 .9A1B13 [ [DE\b [ ECBF31EC3 z19CDA0 #81 ) JC9 2C8B9B491
27158/1: u94 iA3 .84B78AE09592 ;DA ] .F8 A811EE H Q o q9B 8A4 cF1 XF5 g
27158/1: EC ^\n1BE2C1A5C2 V 7FD 094 + (B5D3 :A31B8B128D ' J 18A <897FA3 u
EDIT 7 April 2017
The EINTR problem was the result of a bug in the sample code that I placed on GitHub. The code was not associating the bpf device with the actual interface and Solaris was throwing the EINTR as a result.
Now I'm back to the "message too long" problem that I still haven't resolved.
In gdb, when you run next command. It apply to innermost frame instead of selected frame. How to ask to gdb to break in next line of the selected frame?
For exemple:
Set a breakpoint in a sub-function:
(gdb) b subfunc
Breakpoint 1 at 0x400f09: file prog.c, line 94.
(gdb) c
Continuing.
Breakpoint 1 at 0x400f09: file prog.c, line 94.
94 void subfunc() {
Change selected frame:
(gdb) up
#1 0x0000000000400f7e in main (argc=1, argv=0x7fffffffe468) at prog.c:70
70 subfunc();
I want to stop at line 71 of prog.c:
(gdb) n
95 i = 0;
... but it stop line 95 of prog.c.
I finally found what I want. advance allow to continue until a particular line. Thus advance +1 do the job. It can be abbreviated adv +1.
You can do this with a temporary breakpoint offset from the current line in the selected frame :
tbreak +1
continue
Abbreviated:
tb +1
c
Since the question is
gdb: apply “next” to selected frame instead of innermost frame
The accepted answer is "advance + 1" is not so correct, which only works if the next line of selected frame could be hit.
advance -- Continue the program up to the given location (same form as args for break command)
A general solution is:
Switch to the inferior frame of the selected frame, finish it and step the program.
frame x-1
fin
n
where x is the selected frame.
Ref:
finish -- Execute until selected stack frame returns
next -- Step program
frame -- Select and print a stack frame
http://www.cs.colostate.edu/~cs370/Spring15/Workbook/thread_ex.txt
My professor provided the above sample code (Not duplicating to preserve his IP), and I'm confused by the output.
There are two functions being used as start routines, T1 and T2, and there are two separate for loops starting new threads. There is a tid assigned to each thread that should match the value of t when the thread was created, but there are several threads of the same function with the same tid as seen at the end of his sample output, i.e. there are two T1 threads with the tid 1. Why is this happening? If there are 4 T1 threads, shouldn't it generate tids 0-3?
Your professor designed these incorrectly, t changes its value in the main thread and is accessed by other threads without using mutual exclusion.
Here's what clang's TSan has to say:
==================
WARNING: ThreadSanitizer: data race (pid=5810)
Read of size 4 at 0x7fff193c03e4 by thread T1:
#0 T1(void*) /home/brian/src/so/threading/ex.cpp:16 (exe+0x0000000a0497)
Previous write of size 4 at 0x7fff193c03e4 by main thread:
#0 main /home/brian/src/so/threading/ex.cpp:61 (exe+0x0000000a0881)
Location is stack of main thread.
Thread T1 (tid=5812, running) created by main thread at:
#0 pthread_create ??:0 (exe+0x000000045a8b)
#1 main /home/brian/src/so/threading/ex.cpp:62 (exe+0x0000000a085a)
SUMMARY: ThreadSanitizer: data race /home/brian/src/so/threading/ex.cpp:16 T1(void*)
==================
... followed by ...
T1 [0] count = 12
==================
WARNING: ThreadSanitizer: data race (pid=5810)
Write of size 1 at 0x7ff2f8aa2c80 by main thread:
#0 main /home/brian/src/so/threading/ex.cpp:70 (exe+0x0000000a0964)
Previous read of size 1 at 0x7ff2f8aa2c80 by thread T1:
#0 T1(void*) /home/brian/src/so/threading/ex.cpp:18 (exe+0x0000000a04de)
As if synchronized via sleep:
#0 sleep ??:0 (exe+0x00000003f7bd)
#1 main /home/brian/src/so/threading/ex.cpp:69 (exe+0x0000000a0952)
Thread T1 (tid=5812, running) created by main thread at:
#0 pthread_create ??:0 (exe+0x000000045a8b)
#1 main /home/brian/src/so/threading/ex.cpp:62 (exe+0x0000000a085a)
SUMMARY: ThreadSanitizer: data race /home/brian/src/so/threading/ex.cpp:70 main
==================
T1 thread 1 done.
I'm writing a program that needs to be able to set file permissions, but for whatever reason, chmod is not behaving in the way I would expect it to. For a couple tests, I attempted to create two different files (fileOne.txt, and fileTwo.txt). fileOne.txt should have permissions set to 600, while fileTwo.txt should have permissions set to 777.
Running my program results in the following:
fileOne.txt having permissions set to ---x-wx--T
fileTwo.txt having permissions set to -r----x--t
?? WHAT?
Below is my code. The results of my printf are as anticipated, (600, 777), so why would chmod not like this?
printf("chmod = %d\n", (int)getHeader.p_owner * 100 + (int)getHeader.p_group * 10 + (int)getHeader.p_world);
chmod(getHeader.file_name, (int)getHeader.p_owner * 100 + (int)getHeader.p_group * 10 + (int)getHeader.p_world);
The UNIX file system permissions are octal base and not decimal base. So multiplying it by 100 and 10 will give you unexpected results.
Permissions are reported in octal so 600 is in fact 0600 in C (or 384 in decimal).
Hence code should be:
printf("chmod = %d\n", (int)getHeader.p_owner * 100 + (int)getHeader.p_group * 10 + (int)getHeader.p_world);
chmod(getHeader.file_name, (int)getHeader.p_owner * 0100 + (int)getHeader.p_group * 010 + (int)getHeader.p_world);