cmath library causing runtime error in C++ - c++

DISCLAIMER: I'm not an expert or professional and am simply teaching myself. So my attempts to solve this may have been rudimentary at best.
In C++, whenever I try to compile a program using the <cmath> library, compiling will complete, but when the program attempts to execute I get a runtime error. A Windows dialogue box pops up saying the program has stopped working and is searching for a solution. Instead of just asking you folks, I figured I would try to learn a bit and give it my best shot first. So I loaded up GDB and tried running the program with that to shed a little more light on what is going on.
When running a program including the <cmath> library, GDB immediately outputs the following (regardless of where I place the breakpoint):
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\AE_MailSensor_Plugin.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_outlooksensor.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\ame_smtpsensor.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\OS_Plugin.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for C:\Program Files\DGAgent\plugins\09D849B6-32D3-4A40-85EE-6B84BA29E35B\COM_sensor.dll.
Do you need "set solib-search-path" or "set sysroot"?
If I place the breakpoint on main it stops here. If I allow it to run without a breakpoint or instruct GDB to move to the next step I receive:
Program received signal SIGSEGV, Segmentation fault.
0x6fc85cd1 in libstdc++-6!_ZNSo9_M_insertIdEERSot_ ()
from C:\Users\Me\Desktop\libstdc++-6.dll
From what I can gather, it looks like for some reason my system is having an issue loading the <cmath> library, but I'm still not really sure why. The first three warnings look like files related to e-mail processes, but that makes very little sense to me (but again I don't know very much). So that's about where I'm stuck.
FYI: I am running Windows 7 enterprise, using MinGW and G++ for my compiler.
EDIT: I have tried compiling the program with debug symbols enabled by using -g. When doing this the backtrace is reduced to only #0, #1, and #2 (see comment below for original backtrace) with #2 appended by `at C:\Users\me\desktop\file.cpp: 19. Indicating line 19 which is the last step before the method. This case is repeated in more simple programs with the line indicated being the last step before a method is called.
Is it possible there is a version issue going on akin to this question which points to this forum thread? I'm using gcc version 4.8.1
EDIT: per request of #pm100.
code:
#include <cmath>
#include <iostream>
using namespace std;
int main() {
cout << floor(2.3);
}
for compiling: (i am using notepad++)
NPP_SAVE
CD $(CURRENT_DIRECTORY)
C:\mingw\bin\g++ "$(FULL_CURRENT_PATH)" -o "$(NAME_PART).exe" -g
cmd /c $(NAME_PART).exe

Related

Debugger can't match source or step code in library

I'm trying to debug some code coming from the Crypto++ library, but I'm getting non-sensical information during the session.
The function of interest is DEREncodePrivateKey. Its a member function on DL_PrivateKey_EC<T> (Crypto++ is heavily templated).
228 pk.DEREncodePrivateKey(encoder);
(gdb) s
non-virtual thunk to CryptoPP::DL_PrivateKey_EC<CryptoPP::ECP>::DEREncodePrivateKey(CryptoPP::BufferedTransformation&) const
(this=0x7fff5fbfeca0, bt=#0x7fff5fbfe540) at dll.cpp:690
Line number 690 out of range; dll.cpp has 146 lines.
dll.cpp can be found at trunk / c5 / dll.cpp, and it only has 146 lines ad gdb reported.
The object was dynamic_cast just before the line in question:
const PKCS8PrivateKey& pk = dynamic_cast<const PKCS8PrivateKey&>(key);
I built the library from sources with -O0 -g3, so I think I minimized some/ most of the typical problems.
I've tried building the library and my test programs with different compilers (g++ and clang++), and I've tried debugging it with different debuggers (gdb and lldb). But I still get the non-sensical information and the library cannot be stepped in this area. Other areas are OK (as can be seen before the issue).
I'm also certain that I'm using my version of the library. Its being linked as a static lib using the full path to the library, and info shared confirms Apple is not sneaking in a dynamic library.
I need to step DL_PrivateKey_EC<CryptoPP::ECP>::DEREncodePrivateKey to see what's going on. I think the function that's being called is in eccrypto, but I'd like to see it under the debugger.
Any ideas how to proceed?
It sounds like the line table in the debug info is incorrect. On Mac OS X you can dump the line table with dwarfdump --debug-line appname.dSYM or if you are looking at a specific object file, dwarfdump --debug-line dll.o. From within lldb you can also do target modules dump line-table dll.cpp. My guess is that some function from a header file was inlined into your dll.cpp -- from line 690 -- but the linetable may incorrectly forget to switch from dll.cpp to your header file.
It seems unlikely that you would see the same problem from both g++ and from clang++. I suspect at least part of your project was not rebuilt.
fwiw you can continue debugging here -- the only problem is that the debugger won't be showing you the source as you step through your method. But you can continue to step and I expect you'll be back in your dll.cpp sources again in no time.

OpenCL crashes on call to clGetPlatformIDs

I am new to OpenCL. Working on a Core i5 machine with Intel(R) HD Graphics 4000, running Windows 7. I installed the newest Intel driver with support for OpenCL. GpuCapsViewer confirms I have OpenCL support setup. I Developed a simple HelloWorld program using Intel OpenCL SDK. I successfully compile the program but when run, it crashes upon call to clGetPlatformIDs() with a segmentation fault. This is my code:
#include <iostream>
#include <CL/opencl.h>
int main() {
std::cout << "Test OCL without driver" << std::endl;
cl_int err;
cl_uint num_platforms;
err = clGetPlatformIDs(0, NULL, &num_platforms);
if (err == CL_SUCCESS) {
std::cout << "Success. Platforms available: " << num_platforms
<< std::endl;
} else {
std::cout << "Error. Platforms available: " << num_platforms
<< std::endl;
}
std::cout << "Test OCL without driver" << std::endl;
std::cout << "Press button to exit." << std::endl;
std::cin.get();
return 0;
}
How can it be that GpuCapsViewer successfully confirms OpenCL support and can use it to run its demos, but I can't run my code? Both must be using the same functions, right?
Been working on this for days. Even tried re installing the drivers. Any Ideas?
GpuCapsViewer says:
DRIVER: R295.93 (r295_00-233) / 10.18.10.3496 (3-11-2014)
OPENGL: OpenGL 4.2 (GeForce GT 630M/PCIe/SSE2 with 290 ext.)
OPENCL: OpenCL 1.1, GeForce GT 630M compute units:2#950MHz
CUDA: GeForce GT 630M CC:2.1, multiprocessors:2#950MHz
PHYSX: GPU PhysX (NVIDIA GeForce GT 630M)
MULTI-GPU: no multi-GPU support (2 physical GPUs)
UPDATE:
Compilation line:
g++ -I"C:\Program Files (x86)\Intel\OpenCL SDK\4.4\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"Test3.d" -MT"Test3.d" -o "Test3.o" "../Test3.cpp"
Finished building: ../Test3.cpp
Linker line:
g++ -L"C:\Program Files (x86)\Intel\OpenCL SDK\4.4\lib\x64" -o "TestOpenCL" ./HelloWorld.o ./HelloWorld2.o ./Test3.o -lOpenCL
Finished building target: TestOpenCL
OS: Windows 7 Ultimate Version 6.1 (Build 7601: Service Pack 1)
UPDATE 2, Crash Information:
Problem Event Name: APPCRASH
Application Name: TestOpenCL.exe
Application Version: 0.0.0.0
Application Timestamp: 53bc6ac5
Fault Module Name: TestOpenCL.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 53bc6ac5
Exception Code: c0000005
Exception Offset: 0000000000002cc0
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 56e3
Additional Information 2: 56e3743a8a234df3bdeba0b507471c44
Additional Information 3: 8fe0
Additional Information 4: 8fe0ef5706153941955de850e5612393
UPDATE 3:
Used DependencyWalker(http://dependencywalker.com/) as a substitute for dumpbin. It generates the following warnings:
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 warnings seem to refer to the following DLLs which are all marked with a "Error opening file. The system can not find the file specified(2)" error message.
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
IESHIMS.DLL
UPDATE 4, GDB BACKTRACE:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000402cc0 in clGetPlatformIDs ()
(gdb) backtrace full
#0 0x0000000000402cc0 in clGetPlatformIDs ()
No symbol table info available.
#1 0x0000000000402af3 in main () at ../Test3.cpp:11
err = 0
num_platforms = 0
platform = 0x0
(gdb) backtrace
#0 0x0000000000402cc0 in clGetPlatformIDs ()
#1 0x0000000000402af3 in main () at ../Test3.cpp:11
UPDATE 5, GDB DISASS:
(gdb) disass
Dump of assembler code for function clGetPlatformIDs:
=> 0x0000000000402cc0 <+0>: jmpq *0x4b74e8(%rip) # 0x8ba1ae
0x0000000000402cc6 <+6>: nop
0x0000000000402cc7 <+7>: nop
End of assembler dump.
UPDATE 6, GDB INFO SHARED:
(gdb) INFO SHARED
From To Syms Read Shared Object Library
0x0000000077191000 0x00000000773384e0 Yes (*) C:\Windows\system32\ntdll.dll
0x0000000077071000 0x000000007718eab4 Yes (*) C:\Windows\system32\kernel32.dll
0x000007fefc081000 0x000007fefc0eb13c Yes (*) C:\Windows\system32\KernelBase.dll
0x000007fedf8d1000 0x000007fedf8e96aa Yes (*) C:\Windows\system32\OpenCL.dll
0x000007fefe101000 0x000007fefe1da628 Yes (*) C:\Windows\system32\advapi32.dll
0x000007fefe061000 0x000007fefe0fe4bc Yes (*) C:\Windows\system32\msvcrt.dll
0x000007fefdcc1000 0x000007fefdcde39a Yes (*) C:\Windows\SYSTEM32\sechost.dll
0x000007fefc6a1000 0x000007fefc7cc914 Yes (*) C:\Windows\system32\rpcrt4.dll
(*): Shared library is missing debugging information.
Binary file, x64 and include folders:
https://drive.google.com/file/d/0BxKA63T2GnKMRW02QWZnam5lSGM/edit?usp=sharing
UPDATE 7, GPUcaps situation:
GPUcaps detects 2 GPUs:
GPU 1: Intel(R) HD Graphics 4000
GPU 2: NVIDIA GeForce GT 630M
You can see the screenshot here:
https://drive.google.com/file/d/0BxKA63T2GnKMa00tU1gydGNJeXc/edit?usp=sharing
UPDATE 8:
Per #antiduh 's answer, I have been trying to link directly against OpenCL.dll present in Windows\System32 folder. I am using mingw64. I get this:
Invoking: Cross G++ Linker
g++ -L"C:\Windows\System32" -o "TestOpenCL" ./HelloWorld.o ./HelloWorld2.o ./Test3.o -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/OpenCL.dll when searching for -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/OpenCL.dll when searching for -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lOpenCL
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/msvcrt.dll when searching for -lmsvcrt
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/advapi32.dll when searching for -ladvapi32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/shell32.dll when searching for -lshell32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/user32.dll when searching for -luser32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/kernel32.dll when searching for -lkernel32
d:/ws/apps_inst/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:\Windows\System32/msvcrt.dll when searching for -lmsvcrt
UPDATE 9:
I can now compile, link and run the sample code manually with the following line.
g++ -I. s.cpp -L. -lOpenCL
I simplified everything and it just worked. This is obviously very different from the compile and link commands used by Eclipse. Any idea which of the parameters used by eclipse cause the problem? And also, why is it that eclipse first compiles to object files and then attempts to link them, in two separate steps?
There are three total ways for a program to use external library:
Static linkage: Directly insert the library into your executable. The external library, presented as a .lib file, contains nothing but packaged .obj files. Your program invokes functions from the library as normal. The compiler extracts executable code from the lib, inserts it, and performs full, complete linkage against it. It is as if you compiled against the imported functions like they were from your own source code.
Load-time dynamic linkage, aka 'implicit linking': Load the library when you launch the program. The external library, presented as a .dll containing executable code, and a .lib file containing the exports from the .dll, is tentatively linked against by the compiler and linker. The linker uses the .lib to understand how to call the .dll at run-time, and to put in deferred bindings into your program. When the OS launches your program, it performs 'load-time' linking - it looks up all of the deferred bindings, attempts to find a .dll file, finishes the linkage of the deferred bindings in your program, and allows you to run the file.
"Pure" run-time dynamic linkage, aka 'explicit linking': Directly calling LoadLibrary. Your program has no specific references to any .lib, .dll, or otherwise. Your program starts running, itself calls LoadLibrary with a string path to a .dll. LoadLibrary merges the .dll into your virtual memory, and then your program calls GetProcAddress to get a function pointer to the function you want to call. You then use that function pointer to make calls.
You can't normally link against a dll without the .lib. The compiler wants to resolve those function call references to real addresses, but we don't want to put in real addresses since we want DLLs to be loaded into any arbitrary memory address (DLLs are 'relocatable').
From my understanding, a .lib used as an import library contains stubs that the main program links directly against - so all calls in the program go through the stubs. The stubs then have references to an 'Import Address Table". When the OS loads a DLL into memory for a process, it does so by filling out the IAT. The stub then just calls the DLL by making an indirect jump that references the right slot in the IAT.
So if a DLL MathLib has an exported function Factorial that my exe is importing, then the import .lib file has an actual function Factorial that my exe statically compiles against. That Factorial in that .lib looks like the following psuedo code:
int Factorial( int value ) {
// Read MathLib's IAT which should always be at address 0x8ba100.
// Factorial's real address gets stored in slot 2, so add 8 to the address
// to read from.
__asm jmp *0x8ba108; // nb this is an indirect jump.
}
And then we hope that when the OS loads that DLL, that IAT is filled out correctly, else we jump into nothingness.
So I think what happened is that you were compiling against one .lib, but 'load-time' linking against the wrong opencl.dll. The IAT was never created, or was created in the wrong place, and so you jumped into nothingness; that's why this line created a segfault:
0x0000000000402cc0 <+0>: jmpq *0x4b74e8(%rip) # 0x8ba1ae
So lets figure out why we linked wrong. There could be 3 sets of opencl.dll/opencl.lib files on your computer:
The opencl.lib/dll that comes from Kronos, and is actually just a stub/loader library that figures out what real providers are on your computer and does dispatches function calls to the actual right lib.
The opencl.lib/dll that comes from Intel from their SDK and drivers.
The opencl.lib/dll that comes from Nvidia from their drivers.
Which of these files did you actually have? My estimate is thus:
The opencl.dll that came from kronos got installed into c:\windows\system32.
There is no opencl.lib from Kronos
There was probably no opencl.lib from nvidia, since you didn't have their SDK installed.
You probably had an opencl.lib and opencl.dll from Intel since you did have their SDK installed.
You were definitely linking against the Intel opencl.lib, but appeared to be loading the Kronos opencl.dll in c:\windows\system32. One solution would be to get the program to load the Intel opencl.dll when you run the program by putting their dll in your program's directory.
However, you state that you were able to make things work using this compilation line:
g++ -I. s.cpp -L. -lOpenCL
There's something neat about gcc on Windows - in order to link against a library, you don't need to have the .lib. Gcc figures it out for you by inspecting the dll; other people have figured out how to do the same when someone gives them a dll but no lib. In most other compilers, especially Visual Studio, you need to have a .lib and a .dll to link against something. That's why the Win SDK installs hundreds of .lib (kernel32.lib, eg). Turns out that the compiler can actually infer it if it wanted to, but libs exist as an archaic mechanism.
Anyway, you ran that above gcc link line, it found a suitable opencl.dll using the search path, invented its own .lib for it, and compiled against it; you launched your program, it used that same search path to get an opencl.dll, it was the same one you compiled against, so your program runs. Whew.
I still have some suggestions:
Find an opencl.lib and opencl.dll pair that come from Kronos's "Installable Client Driver" ICD Loader. That loader will then figure out how to bind to a particular provider (nvidia, intel, etc) at runtime.
Distribute the Kronos opencl.dll with your application so that you will never accidentally run-time-link against the wrong file.
Uninstall the Intel SDK, assuming it's providing opencl.lib/opencl.dll files that are specific to Intel.
Some more relevant questions on libs and dlls:
When building a DLL file, does the generated LIB file contain the DLL name?
Why are LIB files beasts of such a duplicitous nature?

Eclipse/MinGW/CDT/GDB and problems with debugging

I have some C++ code and try to debug it.
main.cpp:
#include <iostream>
using namespace std;
int main() {
graph<int> a;
a.add(1);
a.addEdge(1,2);
std::vector<int> answ = a.getAdjacent(1);
for (unsigned int i = 0; i < answ.size(); i++)
std::cout<<answ[i]<<std::endl;
return 0;
}
I have a breakpoint on "graph a;". But when I start debugging, I get:
The target endianness is set automatically (currently little endian)
No source file named C:\Users\home\workspace\graphcpp\main.cpp.
[New Thread 3552.0xdc8]
What's the problem?
This seems to be a relatively frequent reoccurring issue when using eclipse +cdt with gdb. Changing the default launcher from GDB (DSF) Create Process to Standard Create Process seems to solve the issue most of the time.
You can find this option under Preferences->Run/Debug->Launching->Default Launchers:
Also make sure you are compiling with -g debug info enabled.
It seems that only with adding the standard parameters to your 'main()' function is enough (I noticed that you're not using parameters in your 'main()':
check this link
I also see this problem. The folks at LinuxQuestions.org helped me make some progress... http://www.linuxquestions.org/questions/showthread.php?t=518283
It appears that gcc 4.1.0 (ie. that in SUSE 10.1, 32-bit) has an optimization where if you don't use argc and argv in the body of main() those symbols are not present in the binary (even with -g and without any special optimization turned on). The 64-bit compiler doesn't do this incidentally.
You get the "Cannot access memory at address 0x0" from the gdb command line if you simply "break main" and print argc in a program that doesn't use argc/argv (and was compiled with gcc 4.1.0). I note your example doesn't use argc/argv.
This is true for C or C++ compilation.
Eclipse is presumably confused by this error in some way when it hits the first break. I was also getting the inability to stop at further breakpoints until I added code to reference argc/argv, or re-declare main (in C++) as "int main(int, char *[])" so that Eclipse wasn't expecting those symbols.
There is still an error in the gdb output window (no symbol "new" in the current context?), but breakpoints can be set.
HTH,
-nick

C++ runtime errors in CodeBlocks when printing strings with cout <<

I recently started using CodeBlocks and began encountering odd runtime errors which I have traced back to printing strings using cout <<. For example, even the following..
#include <string>
#include <iostream>
int main()
{
std::string str;
str = "Hi!";
std::cout << str << std::endl;
return 0;
}
results in an error. It will compile fine (using Borland) but when I run it I get a pop up window saying 'test.exe has stopped working' and in the console I get the message:
Process returned -1073741819 (0xC0000005) execution time : 1.526 s
Press any key to continue.
It compiles and runs fine in MS Visual C++ and with G++ in Ubuntu.. any thoughts would be greatly appreciated!
Cheers,
Weatherwax
My one-off comment ended up helping solve the problem so here it is packaged up as an answer for future users:
This guy had a similar issue and it ended up being a linker issue which he
fixed. The fix is the last post in the thread, although reading the
whole thread could be useful for you.
Long Story short: Borland compiler is a bit dated and annoying to use. Ended up being a linker issue within borland. Better off using a different compiler like GCC/G++ or Visual Studio compiler.
This answer is here to elaborate on the root cause of the issue.
The reason for your crashing program is because the wrong runtime library is being linked. Specifically, your example is compiled as a single threaded object file(the default) but the linking step is using the multithreaded cw32mt.lib runtime -- the "mt" suffix at the end means multithreaded.
The solution is to make sure the runtime your program is compiled to use matches with the runtime you're linking against. A few ways to do this.
Important bcc32 compile switches:
-tW Windows GUI program. WinMain() is expected
-tWC Windows Console program. main() is expected. default.
-tWR Use dynamically linked runtime. Absence implies static runtime linkage.
-tWM Use multithreaded runtime. Absence implies single thread.
Compiling your example program as single threaded like this works:
bcc32 -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32.lib import32.lib,,
or you can compile it as multithreaded like this(note the -tWM switch matching up with cw32mt.lib):
bcc32 -tWM -oexample.obj -c example.cpp
ilink32 -ap example.obj c0x32, example.exe,, cw32mt.lib import32.lib,,
A third approach that is easier and less error prone is to not call the linker yourself. Instead, let the compiler drive the linker indirectly(similar to gcc):
bcc32 -tWM -oexample.obj -c example.cpp
bcc32 -tWM example.obj -eexample.exe
For your simple example, it can even be shortened to:
bcc32 -eexample.exe example.cpp
Lastly, you can pass the -tW switch multiple times. For example, this command compiles your example as a console program with multithread support and dynamic runtime linkage:
bcc32 -tWM -tWR -tWC -eexample.exe example.cpp
The produced example.exe executable is much smaller and its import table has an entry for CC3250MT.DLL confirming that the borland runtime is dynamically linked.
We should not assume that a non-functioning program is caused by nonconformity to the standard or a bug in the tool we're using without first investigating user error as a potential cause (even though in this case it's tempting to do so). In the OP's case, the code::block IDE didn't have the right commands setup for the toolchain being used.

Cannot Debug Shared Library - Symbols Not Loading Properly

I am currently writing a small library, and I want to check it for leaks (among other things); however, for some reason, gdb is not loading the library symbols. I have read many other posts on here (and various other places on the internet) about this, however, I cannot seem to find a solution. Here is what is going on:
I am compiling the shared library with the following flags (these are included in both the final shared library as well as all object files):
CFLAGS=-Wall -O0 -g -fPIC
Likewise, I am compiling the binary memtest (the client application for the library) to check for memory leaks and such with these flags
CFLAGS=-Wall -O0 -g
Now, I inserted a NULL pointer into the library to test if I could trace through it and "debug" the pointer (i.e. it's making it crash). So I try to run it through gdb, but it's a no go. The output of info sharedlibrary is the same for both the executable and the core:
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
... Some libraries I am not worried about debugging...
0x00d37340 0x00d423a4 Yes (*) /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0 <--- My lib
.... and some more....
(*): Shared library is missing debugging information.
As you can see, it's not loading the debug information. I am uncertain as to why this is. I have built and linked everything with the -g flag, and I even try -ggdb and -g3 but nothing seems to work properly. When I load in a core dump, this is what I see:
...some libs...
Reading symbols from /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0...done.
Loaded symbols for /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done.
...some more libs...
Notice how my library does not give a (no debugging symbols found) error - anyone have any ideas why? As I said before, I am unable to debug this through running the program gdb ./memtest or through debugging the core file.
Thanks for your help.
EDIT It may also be important to note, that (if you didn't realize by path) this library is a local shared library (i.e. I'm using -Wl,-rpath to link/load it)
EDIT2 It seems my version of GDB was out-of-date. Now, I have updated to the latest version from the CVS server (I have also tried latest release version 7.2) and it can "load" symbols. My info sharedlibrary now reads this:
0x00e418b0 0x00e4be74 Yes /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0
However, I am still unable to step through any functions (in the shared library) - anyone have any ideas?
EDIT3 I have also tried to step through linking against a static library (libMyLIB.a) but it still isn't working. My OS is CentOS 5.6; does anyone know of any issues with this system? Also, just another confirmation that my symbols are being loaded (it just can't step through any shared lib function for some reason)
(gdb) sharedlibrary MyLIB
Symbols already loaded for /home/raged/MyLIB/memtest/../lib/libMyLIB.so.0
I found the reason this wasn't working: I was calling an old function call to initialize a pointer in my test executable. Since the object was never being created, I could never step into the library. Once I updated the function call, all worked well.
That said, if anyone experiences similar issues while all symbols appear to be loaded, be sure to check that all pointers are initialized properly even if they have the correct type.