I tried today to find a bug in Thunderbird, or more specifically - the location where it crashes ( the Crash reporter jumps in ).
However when I try to run it in gdb, the program immediately exits with code 06.
And then the Crash reporter springs into action again.
This way, I can never get to the actual point where it dies.
Is there some option I have to pass to make it start successfully?
Thanks!
You need to set the DYLD_LIBRARY_PATH environment variable to tell the loader that this is where all the shared libraries are.
First go to the MacOS directory of you .app.
cd blah/dist/Daily.app/Contents/MacOS
And then set the DYLD_LIBRARY_PATH variable:
export DYLD_LIBRARY_PATH=`pwd`
And finally run the thunderbird executable.
gdb thunderbird
It should then run properly.
This is all mentioned in the Debugging Mozilla docs: Here.
Related
I used homebrew installed gdb, and created code sign for it. It seems I have installed it completed. But when I use gdb command to debug the app in /Applicaions, it always prompted me no such file or directory, I have no idea about it. My system is 10.9.4, and GDB version is 7.7.1.
Wait for your help!
GDB does not automatically load application bundle directories. You need to give it the path to the main Mach-O executable. Something like /Applications/Reveal.app/Contents/MacOS/....
I don't know what the main executable for Reveal.app is named, but if it is named Reveal your command would look like this.
gdb /Applications/Reveal.app/Contents/MacOS/Reveal
Just updated to OS X 10.8.1. I'm not sure if this is the cause, but basically immediately after, programs are unable to check for file changes.
In my makefile, the following command does not work (it doesn't trigger on file changes)
watchr -e "watch('scripts/.*\.js') {system 'make scripts'}"
On Sublime Text, when I make a new file in a folder, that new file is not shown in the sidebar, but it is created correctly in the directly.
This command, however works (based on Node's watch command, I believe):
stylus -w -u nib styles/ie8.styl -o public/styles
Anyone know what's going on or how to debug?
Edit: This isn't working now after rebooting again. I hate this! :/
I also ran into this issue with Sublime Text 2 as well as Guard (it started using a polling fallback).
I believe I found a fix:
Download Onyx and run it with all of the options under the automation tab checked
After it's done shut down your machine and turn it back on
At this point I was suddenly able to see new directories created using mkdir in terminal from within the Sublime Text 2 file browser. Guard was also working without the polling fallback.
I hope this helps, it was really starting to get on my nerves.
This isn't going to be very informative but maybe it will help...
There is a thread in the Sublime Text forums discussing this issue and it doesn't seem to be secluded to OS X 10.8.1.
There also seems to be a thread about watchr not always working, and that issue seems to be platform independent as well.
I would bet that you've become the unwitting victim of the 'Mac OSX' env vars change ...
Please take a look at the following to determine if your env vars are set correctly on Mountain Lion as the environment.plist is now deprecated ...
Env Plist Deprecated
Mac OSX - Sublime
I am trying to run our App on Mac Lion. App is built on Snow Leopard 10.6.8, packaged using package maker. We are linking dynamically to libCurl(3rd party lib). On snow leopard it works. On Lion when I install and click the app icon it fails in call to curl_easy_perform (from libCurl). But when I right click the app icon, click show package contents, and goto /Applications/MyDir/OurApp.app/Contents/MacOS/OurApp and then try to run that unix executable, then it works. I used otool to check the lib paths and they all seem correct.
Can someone help me why it fails when I click the .app? I thought .app is a soft link to the main executable. so if the executable works, then .app should also work.
Do I have to tell the path of the lib in .app? if so, how?
The dynamic linker "dyld" and related programs such as "otool" are influenced by environment variables. Environment variables can vary by process: the Finder has a unique copy of environment variable settings, and so does each shell in a terminal window.
As you can see if you run "man dyld", there are many variables that can influence the behavior of these programs.
If you're seeing different behavior from the command line than in the Finder, I imagine that at least one of the special linker variables has been set in your terminal. It is probably instructing the linker to look in places for libraries that are different from the linker's defaults (or whatever the Finder uses).
You can run "env | sort" from your terminal to see what's been set.
I am building a program on Mac OS that uses the curses library. When I attempt to run it inside Xcode, I get this error message:
Error opening terminal: unknown.
And then curses calls exit.
Obviously, it works from a Terminal window.
Is it possible to launch my program in a terminal window from Xcode? I know that I can use the "Wait for XXX to launch" option, but a lot of Xcode's helpfulness in starting programs vanishes that way, so I would be looking for another way.
Xcode uses GDB, or LLDB for debugging.
You can invoke them directly from a terminal. This way, your executable will be attached to a working one.
Try:
gdb path/to/my/executable
Then, from the GDB prompt, type:
run
To start your program in debugging mode.
Take a look at the GDB manual for learning stuff like debugging commands, breakpoints, etc.
I have a XCode which builds and runs under XCode.
I would like to know if it is possible to debug it using a gdb I build under Mac OSX (gdb 7 to be specified). If yes, can you please tell me how can I do that?
Thank you.
gdb-7.0 reverse debugging currently can only work with two classes of targets:
1) a remote simulator/emulator/virtual-machine that supports going backwards, or
2) the built in "process record" target, which at present has only been ported to x86-linux, x86-64 linux, and moxie linux.
Well, now -- I take that back. I recently discovered that process record can work with any remote x86 target, so if you're connecting with your macintosh target via "target remote", you might just be able to do it!
There is an online tutorial for process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial
More info about process record here:
http://www.sourceware.org/gdb/wiki/ProcessRecord
And about gdb reverse debugging here:
http://www.sourceware.org/gdb/wiki/ReverseDebug
So you want to use your own version of gdb to debug your executable? Easy!
Open Terminal, and do something like this:
$ cd <directory where Xcode project lives>
$ cd build/Debug (for example - depends on project configuration)
$ /usr/local/bin/my-gdb ./MyExecutable
Of course, specifying the actual path to your custom gdb version.
XCode's debugger is gdb (likely with Apple-specific modifications.) When you debug an application you can get to the gdb command line by opening the Console from the Run menu.
What requirements are imposed on your application that would require you to debug with your own version of gdb?