Trying to debug an application written in Qt on mac (10.6.8). Qt 4.8.6, QtCreator 3.2.0, I set up the debugger System GDB at /usr/bin/gdb and compiler gcc-4.2
I want to debug the code...
I get in the application output window
Debugging starts
Debugging has failed
Debugging has finished
(and no breakpoints were hit, nothing has started in code)
I opened the debug log window, and the only suspicious things I saw were
....
111^error,msg="Undefined command: \"python\". Try \"help\*.*
NOTE: ENGINE SETUP FAILED
State Changed From EngineSetupRequested(1) to EngineSetupFailed(2)
HANDLE RUNCONTROL FINISHED
.....
On the left, some of the commands had
109-interpreter-exec console "python sys.path.insert(1, "/Volumes/QtCreator/..."
110-interpreter-exec console "python sys.path.append("/usr/bin/data-directory/ python)"
111-interpreter-exec console "python from gdbbridge import *"
I checked that python is installed... i can type python from anywhere and get its command prompt so it is on system path...
I read something about having to sign a fsf debugger but the one I am using is not a fsf debugger ?
What can I do to debug my apps in macx ?
Edit: Tried gdb from command line, with the app as argument
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
...
This GDB was configured as "x86_64-apple-darwin"...
warning: Unable to read symbols for QtSvg.framework/Versions/4/QtSvg (file not found).
warning: Unable to read symbols from "QtSvg" (not yet mapped into memory).
warning: Unable to read symbols for QtGui.framework/Versions/4/QtGui (file not found).
warning: Unable to read symbols from "QtGui" (not yet mapped into memory).
warning: Unable to read symbols for QtCore.framework/Versions/4/QtCore (file not found).
warning: Unable to read symbols from "QtCore" (not yet mapped into memory).
warning: Unable to read symbols for QtNetwork.framework/Versions/4/QtNetwork (file not found).
warning: Unable to read symbols from "QtNetwork" (not yet mapped into memory).
Reading symbols for shared libraries .
... some warnings that .o is more recent than .dylib in dependent libs... but that I don't have to step into so I don't care...
...
warning: Could not find object file "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/crt3.o" - no debug information available for "darwin-crt3.c".
.... done
So I type run
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff83872c00 in strlen ()
I don't know where that is (I do but really can't see it) or if it is an actual string pointer or something else...
I don't know where the breakpoints would be, the entire source is very long and contains lots and lots of files so I really don't know how I can do it with gdb from command line...
But it seems that it did get started, without complains about python ?
The warnings at start - could that mean that there is still hope, that it is possible to somehow configure gdb to run with Qt if it learns about its libraries ?
By the way... searching for the missing libraries...
QT 4.8.4 debug libraries not found on Mac OSX
I have tried to replace my debugger (in Qt) using lldb and qmake - in both cases I got an error "Unable to create a debugger engine of the type 'No engine'"
Edit: Another suggestion I read about is to recompile Qt Creator Binaries to add debug symbols... I hope that is not what I have to do because
"Note: With Qt Creator 3.2 we drop support for OS X 10.6 (Snow Leopard). The technical reason for this is that Apple does not support any kind of C++11 on that OS version. Of course that does not affect on which platforms you can run your Qt applications on. But it is not possible to run the Qt Creator 3.2 binaries on 10.6, and it also is not possible to compile Qt Creator 3.2 on 10.6 with the tool chains provided by Apple." (from release notes)
Update: I was able to find the cause of the error above (the KERN_INVALID_ADDRESS) by placing a zillion qDebug() statements... Though that was not what I am trying to accomplish, one error out of many.
I still have lots of errors... Attaching a debugger would be wonderful. I have listed the required libs for the program - they seem to exist. Not sure if they are "debug" or "release" libraries. .... But I am not trying to step through the Qt sources, so why would it matter if I have debug symbols for them ? And if they were "release" type libs, then my whole program, build in "debug", would not execute or even fail to build ? Since I am building my code in "Debug" mode and it executes, the libraries must be correct, right ?
So confusing...
QtCreator 3.2 (and a few versions before that) requires a GDB that has Python scripting enabled (or LLDB, or CDB on Windows). On Mac, Apple's GDB doesn't have Python scripting, and therefore cannot be use with Qt Creator. FSF GDB works for some projects on Mac, but in general LLDB is preferable there.
Your "GNU gdb 6.3.50-20050815 (Apple version gdb-1518)" is such an non-Python-enabled Apple build.
Related
I'm trying to debug a Fortran 95 program using gdb 4.8. When I encounter a breakpoint (or the error I'm trying to debug), I cannot print any information on local variables using the info command. I also get a No symbol tape information available error when running bt full.
I don't believe this is related to the version of gdb as I first tried installing the version from Homebrew and got the same error. I then removed the Homebrew installation and compiled and installed the latest available version of gdb from source. My Fortran file is compiled with the -g flag and the -fbacktrace flag and has no explicit optimization flag, but I have attempted to compile with -O0, -O1, -O2, and -O0. All give the same error.
Possibly related is the fact that, upon running the code, I get loads of warnings. Here is a small excerpt:
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_c8_i4.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_c8_i8.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i16_i16.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i16_i4.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i16_i8.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i4_i16.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i4_i4.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i4_i8.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc-dmSW1S/gcc-4.9.2/build/x86_64-apple-darwin14.0.0/libgfortran/.libs/pow_i8_i16.o': can't open to read symbols: No such file or directory.
I have gcc installed by Homebrew but which gcc returns /usr/bin rather than /usr/local/bin, so this is is probably the default Mac install. /private/tmp/gcc-dmSW1S/ does not exist. Can provide any other information needed.
You are using a sufficiently ancient version of gdb that it won't be able to read debug symbols from your objects compiled with gcc 4.9. The 4.x version of GDB are at least 15 years old and and date back to the gcc 2.95 / egcs era of compilers. Numerous ABI and debug symbol changes make gdb 4.x unsuitable for debugging objects compiled with GCC 4.9.
For objects compiled with GCC 4.9 and default debug symbol output (DWARF4 iirc), you'll want GDB 7.5.1 or newer. The current GDB release is 7.9.
i'm tryin to debug (actually i just want to understand the program on assembly level) a program. Usin gdb is ok but in tui mode it would be just great, unfortunately i get an error when i'm debuggin in tui while displaying the assembly and source code (-g option in gcc) mode sayin: error while reading shared library symbols
I can run the program if i do not show the assembly code but that is not what i want, i really want to step through every assembly line to fully understand the program. Also, when i try this with si sometimes i get an error for example in printf but that's another story
so any tips? Note:this is not a bug of my program, i tried this with other programs
Your shared libraries were not compiled with symbols enabled. You need to look for, usually, "debug" versions of gcc libraries (or your other libraries that you are linking against). If you have custom libraries that you are building, add the -g option to the gcc commands that are being run to compile them.
My setup is as follows:
OS: Windows 7 Home Premium 64-bit
Eclipse: Helios 3.6.1 64-bit with CDT
and Photran
Java SE Runtime
Environment: 1.6.0_21
Java Hotspot: 64-bit Server VM
(build 17.0-b17, mixed mode)
Cygwin 1.7.2 (32-bit)
My initial test Fortran application simply prints 'Hello World!' and exits.
The code builds and runs fine, albeit with the following 2 Warnings in the Problems tab in Eclipse
Description Resource Path Location Type
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c) HelloFortran Unknown C/C++ Problem
Error launching external scanner info generator (gcc -E -P -v -dD C:/Users/Joe/workspace/.metadata/.plugins/org.eclipse.cdt.make.core/specs.c) HelloFortran Unknown C/C++ Problem
The problem comes when trying to debug the app as a Local Fortran Application which results in this error:
cygwin warning:
MS-DOS style path detected: C:\Users\Joe\workspace\HelloFortran
Preferred POSIX equivalent is: /cygdrive/c/Users/Joe/workspace/HelloFortran
.gdbinit: No such file or directory.
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
auto-solib-add on
Undefined command: "auto-solib-add". Try "help".
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 7060.0x10dc]
[New thread 7060.0x16c0]
I'm guessing the entry points aren't found because it's expecting 32-/64-bit DLL and getting the other type (correct me if I'm wrong). The GDB version is as follows:
GNU gdb 6.8.20080328 (cygwin-special)
GDB configured as "i686-pc-cygwin"
Running GDB from the command-line gives:
[New thread 5768.0x15a0]
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x75230000 not found.
Error: dll starting at 0x76ba0000 not found.
Error: dll starting at 0x76aa0000 not found.
[New thread 5768.0x46c]
hellofortran () at ../HelloFortran.f90:1
1 program HelloFortran
Current language: auto; currently fortran
If I'm reading that correctly the application does run in GDB and I am able to step through it, but what are the missing DLL errors about?
Dependency Walker gives the following errors for my HelloFortran.exe
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
The missing DLLs seem to be IESHIMS.DLL (2) which from my quick research doesn't seem to be a big issue but I don't see any reason my application would need to reference this DLL so I don't think this is leading to the errors in GDB.
All of the modules have a CPU type of x64 except for:
CYGGCC_S-1.DLL
CYGGFORTRAN-3.DLL
CYGWIN1.DLL
HELLOFORTRAN.EXE
which have a CPU type of x86
I'm concerned the missing DLL errors could harm my ability to debug my program properly (although the program will eventually run on a Unix-based HPC so I shouldn't run into these issues there since all those DLLs seem to be to do with Cygwin).
My questions:
Why do I get missing DLL errors? (Would switching to 32-bit versions of Eclipse/JVM etc fix this?)
Am I
okay to continue, or should I solve
the missing DLL errors (and if so,
how)?
Edit: My test program is as follows:
program HelloFortran
! Force variable declaration
implicit none
! Print 'Hello World!' to the main output
write (*,*) 'Hello World!'
! End program
end program HelloFortran
Why do I get missing DLL errors?
When Win/x64 sends a DebugEvent to 32-bit process about a 64-bit DLL that is part of that process, it necessarily truncates the load address (64-bit load address doesn't fit into 32-bit LPVOID). The end result is that the debugger sees a DLL load event, but can't find any DLL at that address; so warns you.
(Would switching to 32-bit versions of Eclipse/JVM etc fix this?)
No: this is fundamental to debugging any 32-bit process on x64 (at least with 32-bit debugger). I think you would get rid of the warning if you use x64 version of GDB, but I am not sure if GDB/x64 can debug 32-bit processes on Windows (x86_64 GDB has no trouble with i386 processes on Linux due to "multi-arch" support; I don't know if "multi-arch" is present in Windows version).
I'm concerned the missing DLL errors could harm my ability to debug my program properly
You shouldn't be.
I don't see any reason my application would need to reference IESHIMS.DLL
What made you think it's IESHIMS.DLL?
More likely what you see is WoW64.dll and friends.
Every 32-bit application running on Win/x64 references WoW64.
I am developing a program on OSX 10.6.4 (Snow Leopard), and I want to be able to run the compiled product on other Intel Macs, some of whom may not have XCode isntalled.
To simplify things, I first wrote a Hello World program.
#include<stdio.h>
int main() {
printf("Hello world!\n");
return 0;
}
If I compile it as
gcc -static prog.c
I get the folllowing error:
ld: library not found for -lcrt0.o
I don't know where to find this library. Now, some people have mentioned that I should not compile statically on macs since the system shared libraries should be available everywhere (third party libraries can be manually linked). However, when I try to run this Hello World program on another mac, I get the folowing error:
dyld: unknown required load command 0x80000022
Trace/BPT trap
So, how do you compile a program on mac so that it can be distributed? I am not having architecture issues, as most computers I am interested in are Intel Macs.
Don't use -static. Your executable will run fine on other 10.6.x x86 Macs. If you want to deploy on pre-10.6 Macs then you'll need to use the appropriate SDK but apart from that it should "just work", regardless of whether the developer tools are installed.
It might be worth using XCode to create your executable, using the Command Line program template (basic Unix executables), simply because it will manage a lot of the compiler options for you (including which SDK you are compiling against / which versions you are targeting).
My guess is that a default commmand-line compilation is going to compile against the current system libraries (10.6.4).
I have a following setup. Although my working setup deals with ARM compiler Real View Developer Suite (RVDS) 3.2 on a Windows host, the situation could be generic for any other C compiler on any host.
I build a ARM library (static library - .a file) of C code using RVDS 3.2 compiler toolchain on Windows host. Then I link this library with an application using an ARM-Linux compiler toolchain on a Linux host, to get a ARM executable. Now when I try to debug this generated ARM executable on Linux using gdb, by trying to put a breakpoint in some function which is present in the library that is linked, gdb is not able to put breakpoint there citing source not found. So I manually copied all the source files(*.c) used to create the library in the Linux folder where the executable file is present. Still gdb fails to put a breakpoint.
So now I started thinking:
How can I do source level debugging of this library which I create on Windows using a different compiler chain by launching the executable which is generated by linking this library to an application, in gdb. Is it possible? How can I do it? Is there any compiler option in RVDS compiler toolchain to enable this library source level debug?
Do I need to copy the source files to linux in exactly same folder structure as that is present in windows for those source files?
You could try to see if mimicking the exact same directory structure works. If you're not sure what directory structure the compiler annotated in the debug info in the executable, you can always look at it with dwarfdump (on linux).
First, GDB does not need any source to put breakpoints on functions; so your description of what is actually happening is probably inaccurate. I would start by verifying that the function you want to break on is actually there in the binary:
nm /path/to/app | grep function_desired
Second, to do source level debugging, GDB needs debug info in a format GDB understands. On Linux this generally means DWARF or STABS. It is quite possible that your RVDS compiler does not emit such debug info; if so, source level debugging will not be possible.
Did you build the library with debugging enabled (-g option)? Without that, there would be difficulties identifying lines etc.
I've found that -fPIC will cause this sort of issue, but the only work around I've found is to not use -fPIC when I want to debug.