I’m working on an engine that runs both on Windows and Linux. I’m not very knowledgable regarding Linux programming though, so bear with me.
Just recently I replaced my GF2 with a GF4 and installed the new NVIDIA 3123 drivers. And now when I run samples of my engine that use some more “advanced” features (such as render to texture, or vertex programs), I get a crash most of the time…but not always.
Inspecting the core dump with gdb gives the following backtrace:
#0 0x4174a53a in __nvsym12838 () from /usr/lib/libGLcore.so.1 #1 0xffffffff in ?? () #2 0x00000002 in ?? ()
Error accessing memory address 0x1800067: No such process.
As far as I can tell so far, it always happens in __nvsym12838 (or another number, after a reboot, but the number always stays the same for one session) and all the other addresses are also always the same. The only thing that changes is the last memory address, before it says “No such process”. I don’t know what’s wrong.
Did I install the driver incorrectly?
Of course it might be that I changed something in my engine that causes this, but since I’m using the same code under both Linux and Windows, and it works fine under Windows, I’m kind of lost on what could be wrong.
Also the stack trace isn’t very revealing to me. And the funny thing is, like I wrote above, that sometimes, but not very often, the samples run just fine.
Demos that use features like vertex programs in our SDK have no trouble running under Linux so it could be a problem with your code.
Have you tried stepping through the code in a debugger and seeing where the crash occurs? Download DDD (may already be installed on your system) and debug your compiler program by executing ddd like this: ddd <your program executable> then you can set breakpoints and step through the code like you can with Visual C++.
If you can create a small program that demonstrates the problem I will try it out on my Linux systems and see if I can locate the error and file a bug if necessary.
Aaah, thanks for the hint with ddd. Didn’t know about it, and being used to the Visual C++ debugger I was a bit at a loss with gdb for a moment
I did some stepping through my code and found out that in my math library I get a couple of asserts when I try to calculate my projection matrix. In particular, it happened that certain values in the projection matrix were NaN.
But the failed asserts were kind of strange. For example, an assert checks that the float value for the aspect ratio I specify for the projection matrix is > 0. In the watch window the debugger tells me that the aspect ratio is 1.05345 and still the assert fails. Or I have a Deg2rad function which I directly call with a float parameter value of 60 and in the watch window it tells me the value of the float parameter is 6.03453e-44?
…oh boy, Linux programming is still a mystery to me.
In case someone’s interested, the weird problems I had with random crashes and strange asserts was caused by some kind of library mismatch of gcc 2.96 and gcc 3.1 libs. A couple of weeks I ago I tried out gcc 3.1, but it turned out that some of the libs I use didn’t properly work with it, so I switched back to my old gcc 2.96 version. I accidentally forgot to delete a couple of lib files. Removing them got rid of all the weird stuff, and now everything runs just with a recompile of the code as expected and gives the same results as under Windows.
Thanks for pointing me to ddd I guess I should have searched for a Linux debugger earlier.
Hehe, I had a similar problem myself. I attempted to install gcc3 and gave up halfway through due to many problems. But somehow the gcc3 stdlib was still installed although everything else was gcc 2.96
I guess I should have searched for a Linux debugger earlier.