Blog
Linux Debugging
Date: 17/11/2003
After using RH9 for a good 4 months now, I'm starting to get to the bottom of all the issues. Firsly I've switched off NPTL completely. As pretty much everything is not ready to use it. Like GDB and Valgrind which my life revolves around when I'm coding. So once that was sorted GDB v6 started sucking less, and could actually see the improvements over v5.3, and Valgrind mysteriously started working again. Which meant at the end of the day I found a number of new memory related bugs in LGI.

Pretty much all my apps had been crashing and hanging in really weird places, and GDB was absolutely no help in finding these errors. And without Valgrind I would probably have never found them, when Valgrind works it's brilliant.

The one thing I do appreciate about the new version of GDB is it's ability to correctly display the stack with pthread calls in amongst the normal calls. However it's still quite common to get silly errors like "can't find thread info" or "no such process" or what not. It's really a toy debugger compared to M$'s Visual C++ debugger. I do miss being able to set breakpoints while the app is running and being able to view an entire class, with all it's members easily. But I guess being able to setup core dumping for post mortems is about the only advantage GDB has over VC++ 6.

I have moved some of the dynamic shared library loading out of threads and put it into the main thread of Scribe (under Linux), which slows down the startup when you have plugins loaded but it should mean in the long term it's more stable. It seems that dlopen and dlclose are not that threadsafe. Heres hoping for someone to fix that in the 2.6 kernel.
 
Reply
From:
Email (optional): (Will be HTML encoded to evade harvesting)
Message:
 
Remember username and/or email in a cookie.
Notify me of new posts in this thread via email.
BBcode:
[q]text[/q]
[url=link]description[/url]
[img]url_to_image[/img]
[pre]some_code[/pre]
[b]bold_text[/b]