I have an Xcode project with a single Scheme that does nothing more than launch an OS X app in Debug configuration. The app is not built by the project, and the project does not have any targets. The Xcode project just launches the app from a Scheme. The app was originally built in Debug mode, via an external command-line build script, and contains a number of dynamic libraries (dylib's) in addition to the main executable.
After launching the app in this way through Xcode, if the app is stopped by an assertion statement (or is simply manually paused), the resulting call stack reveals nothing more than address pointers. There are no symbols displayed:
However, if I force the assertion to continue, the app crashes and produces a fully-symbolicated crash report, despite an absence of dSYM files anywhere in the app distribution.
[Edit]: In addition, many of the symbols appear at the top of the Debugger Source Editor in many (but possibly not all) of the calls in the stack:
rendersystemtest`CMaterialSystem2AppSystemDict::SetupMaterialSystem:
rendersystemtest[0x1cfb99] <+1753>: movb $0x1, -0x51(%rbp)
rendersystemtest[0x1cfb9d] <+1757>: movq 0x85c4e4(%rip), %rax ; (void *)0x0000000000000000
rendersystemtest[0x1cfba4] <+1764>: movb -0x51(%rbp), %cl
rendersystemtest[0x1cfba7] <+1767>: movq (%rax), %rax
rendersystemtest[0x1cfbaa] <+1770>: cmpq -0x8(%rbp), %rax
rendersystemtest[0x1cfbae] <+1774>: movb %cl, -0x101(%rbp)
So, the symbols exist somewhere, they are just not being shown in the UI call stack.
Furthermore, this lack of call stack symbols is a recent result. Previously, the same executable displayed a symbolicated call stack when paused or stopped by an assertion:
My questions are:
What could have caused Xcode to stop showing symbols in the UI call stack?
If the symbols are available for a crash report, why can't Xcode display them in the UI call stack?
[Edit]: Why is Xcode displaying the symbol in the Debugger Source editor, but not in the call stack itself?
[Edit 2016-11-05] After further research, this seems to be environmental...and possibly related to an update to macOS Sierra. This problem does not occur on a similar MacBook running El Capitan.
Still have no idea what the root cause is though. Any input would be appreciated.
Related
I have crashes coming in via XCode's Organizer format he App Store. The crashes do not seem to reference any of my code and they seem relatively consistent. Im not sure how to figure out where the issue is since nothing int he stack traces seems to directly implicate my code. Only one StringByReplacingOccurencesOfString seems to be listed in the latest crash, but not in previous similar ones (See last image):
I am not sure how to dig in here and get more detail since the symbolicated crash report does not seem to give me any real detail to go on.
Here are the other thread states:
Last version crashes:
I am new to assembly language, and I am using macOS. The book I read uses DOS's debug instruction, which could see the values in registers at any time without set breakpoints in some executable programs like lldb, and could execute basic assemble instructions like mov ax, 2000. I know that macOS runs on a x86_64 machine, which is different from DOS. I simply want a way that can inspect and interact with registers/memory in terminal without an formal assembly program.(For example, in DOS, type in debug -r and I can see all the values stored in registers).
In lldb - the stock MacOS debugger
register read
will show you all register values
Also possible with shortened syntax for quicker typing
re r
If you want the floating point registers (xmm* for x86-64) too included
re r --all
If you want particular register value
re r rax
lldb is used in current versions of Xcode the MacOS free programming IDE from Apple which allows you to target MacOS & iOS.
You can also go with the terminal route when you would run your program with:
lldb ./yourProgram
But this approach will require a lot of typing and knowledge about your binary, so I don't recommend it for starters.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I really need some help here. I've been searching online for about 2 days now and can't seem to find an answer to the problems that I got.
I downloaded nasm and installed it it seems to work but I can't seem to find any example code that works on windows 64bit (it would be awesome if you could make a simple hello world example for me or something).
(And how to compile it)
How would I turn the .o file into a .exe?
How would I accesses the screen or gpu memory (I think) to print stuff on the screen (like some sort of console application)?
There a a few things to consider when programming in assembly using NASM under Windows:
NASM is just an assembler
A linker is needed to create an executable.
Windows API are implemented as a user space library.
The library is not entirely in user space, some functions cross the boundary, but the interface to the application is a set of DLL, most notably: kernel32.dll, user32.dll and so on.
Windows' executables can have different subsystems.
Among the others the IMAGE_SUBSYSTEM_WINDOWS_GUI and IMAGE_SUBSYSTEM_WINDOWS_CUI are the most used, the former being used by applications that create windows and the latter by applications that use a console1.
The linker takes to COFF object (.obj) file generated by the assembler, takes a set of library definitions (.lib) and perform these important steps:
It resolves the call to external functions found in the object file.
A function marked as external is meant to be found in one of the library definition, the linker then fixes the call instruction to point to a location where the address of the function will be found at run-time.
It add the dependency libraries to the final executable.
This is done with the help of the PE file format, basically if F if found on the library L then L is added to the dependencies list along with a location where to write the address of F.
The loader will do the rest.
The linking is actually more complex than that.
It is also responsible for setting the various PE flags and settings, including the subsytem and the entrypoint.
To write an executable using NASM with need:
A linker.
The set of library definitions.
These can be found in the Windows SDK2.
The linker we will use in this example is the Microsoft LINK linker.
As #CodyGray pointed out in its comment (quoting because I'm lazy):
The Windows 7 version of the SDK that you linked does include all of the build tools. The Windows 8 SDK changed and no longer ships with the command-line build tools, forcing you to download a Visual Studio package
Once we have the tools, we can start programming.
We will use WriteFile to write a string to the standard output (like we would in Linux assembly).
The handler to the standard output must be retrieved with GetStdHandle though.
In Windows you can exit a process with a ret even with no CRT (C run-time) linked (i.e. in a bare process).
I won't explain the Window 64 ABI nor the trickery of programming in 64-bit.
BITS 64
DEFAULT REL ;RIP relative addressing by default
GLOBAL main ;Main must be visible to the linker
;Function the linker will look for in other modules (libs or objs)
EXTERN WriteFile
EXTERN GetStdHandle
STD_OUTPUT_HANDLE EQU -11
SECTION .data
strHelloWorld db "Hello world!", 13, 10, 0
lenHelloWorld dd $-strHelloWorld
hOut dd 0 ;Will store STDOUT handler
SECTION .text
main:
sub rsp, 30h ;20h (Home space) + 10h (params)
;Get STDOUT handler (Handler are 32-bit values)
mov ecx, STD_OUTPUT_HANDLE
call GetStdHandle
mov DWORD [hOut], eax ;Useless as now, for future reuse
;Write strHelloWorld to STDOUT
mov ecx, eax
lea rdx, [strHelloWorld]
mov r8d, DWORD [lenHelloWorld]
xor r9, r9
mov QWORD [rsp+20h], r9
call WriteFile
add rsp, 30h
ret
To create an executable from this source, we first assemble it into a 64-bit object file:
nasm -fwin64 hello.asm -o hello.obj
then we link it against the kernel32 library (the only one we need):
link /MACHINE:X64 /SUBSYSTEM:CONSOLE /OUT:hello.exe /NODEFAULTLIB /ENTRY:main kernel32.lib hello.obj
the CLI switches are pretty straightforward, NODEFAULTLIB avoid linking with MSVCVRXX.lib, the Microsoft CRT.
Those are the minimal switches necessary to build an executable in this example.
I assume you are smart enough to fix the path issues when issuing the commands above, particularly you can tell link where to find the lib files.
For this example I just copied them from the SDK installation folder.
As proposed in other answers, you can use other assemblers that may came with a linker.
Another possible developing environment is to use gcc (either inside cygwin or as mingw) to perform the linker step.
1 In this case Windows automatically create a console for the application and set the standard handlers appropriately. GUI application can recreate the console too (or more than one), so IMAGE_SUBSYSTEM_WINDOWS_GUI must be intended as "No console by default".
2 The version linked is the first Google result, invest more time in finding a suitable version. Also, I'm not sure if there is a linker in the Windows SDK or you need to download a Visual Studio instead.
Download Flat Assembler.(Download->flat assembler for windows)
http://flatassembler.net/
Extract zip.
Goto 'examples/win64/pe64demo/'
open 'pe64demo.exe'
(source code is in 'pe64demo.asm')
Am attempting to learn Swift and am building an audio application inside of OSX.
I am attempting to debug the code, and I am experiencing the following error:
ESX_BAD_INSTRUCTION(code=EXC_I386_INVOP,subcode=0x0) at runtime during debugging.
No further information is available from the debugger.
Now, of course I would normally be hard at work by this point googling for a solution, but there is more information...
The function in which this error appears is fairly large, and the debugger line is about 3 lines of code from the top of the function.
Problem is, that the crash happens way down inside the function - in the main loop, and after it has run over 80 times. The debugger appears to be moving its pointer back earlier in the code which is pretty confusing. I can confirm that the execution thread is way further on than the position in the code where the crash is being reported.
Due to the fact that the stack location is incorrect, all the debug variables are missing in the debugger.
Can the debugger be forced to report the correct stack location?
People,
I have just working on OSX 10.9, and have a crash at hand to debug.
I see OSX has LLVM and LLDB which replaces well known and well documented gdb.
Anyway, I see in crashreport the precise stack trace, and that's pretty impressive from Apple.
However, I can get to image lookup in lldb and print the API name.
When I use verbose option with image lookup it prints few extra information, however, I am still not able to view local variables in the specific API.
I tried image dump, image sym-tab etc and other lldb options.
None of them seems to helping. Scanned through StackOverflow to see if its there's but not luck yet.
Therefore I have the Q
From OSX crashreports we cannot get stack-trace with local variables/arguments values?
How do we see a function arguments/locals variables using LLDB when we a OSX crashreport handy.
I see frame variable etc works fine when attaching to a running process, however these doesn't work when I crash the process and try to see the locals/arguments.
Request you to please guide.
THank you.
The CrashReporter output consists (mainly) of a backtrace of all the threads in the program, the list of libraries/frameworks that were loaded at the time (with their load addresses and Mach-O UUIDs to identify which build of each binary was being used) and the register context for the frame that crashed.
image lookup -va in lldb will show you where the arguments/variables were located at that given pc. If a variable is stored in register rbx at that point, image lookup will say it's in rbx. Often times a variable is stored on the stack and the location will say something like rbp-40 where rbp is the frame pointer register on x86_64. In that case, it means the variable is currently available on the stack at the value of rbp minus 40.
Crash reports do not include any of the stack contents -- they intentionally don't include things that might be sensitive. For instance, your program might have a password in plaintext in a stack local variable.
If a variable you're interested in is stored in a register at the point of the crash, you can use the register context section of the crash report to figure out what value was in there.
Often it's not quite that simple. If you can read your way through assembly language, the best way to figure out what really happened is to disassemble the crashed function and use the register context information to understand why the final instruction resulted in the crash.