|
|
Theodryck
Apprentice
Group: Members
Posts: 13
Joined: Feb 18, 2009
|
#17 Posted Jul 17, 2009, 4:31 pm
|
Well yeah, I can see how you call it that. But I would think of it more as a memory allocation error rather than a leak which is what valgrind is most suited for. As of right now I'm trying to track down why str_dup is filling the buffer random garbage rather than what it's supposed to and why linked lists aren't filling the way they should. Again, I know it's related to glibc and the updated header files but I haven't found it just yet.
|
|
|
|
|
Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#19 Posted Jul 17, 2009, 9:56 pm
|
str_dup() isn't part of glibc. strdup() is though. str_dup() is an elliptical-shaped wheel reinvention unless it's been changed to be a wrapper for strdup(). Default, no.
So I'm not sure how glibc would be at fault here, anyways.
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
Last edited Jul 17, 2009, 9:56 pm by Runter
|
|
|
|
Theodryck
Apprentice
Group: Members
Posts: 13
Joined: Feb 18, 2009
|
#21 Posted Jul 18, 2009, 5:55 pm
|
Compiles fine. 0 warnings or errors on a clean/full compile. And I know what str_dup and strdup are. I personally don't have anything against glibc as it relates to linux. But it's not even really needed for mud code and with all the new header files and library changes it makes it tough to sift through. You yourself have been know to say so about glibc yourself, Samson. And glibc *does* give mud developers fits on a daily basis. It's open source and bound to have compatibility problems here and there. That's the nature of the beast.
I'm not blaming gcc4 or glibc for my problems as they are needed updates in the evolution of linux. But I do blame them as they relate to my mud because mud code is from the stone age as far as computers go. Still valgrind itself points to outside header files and not mud files as the source of my problems.
We can toss this stuff back and forth all day but in the end I'm still stuck looking at my screen with valgrind telling me unitialized variables from ctypes.h or bits.h and etc. Those are included files with the gcc4 package. Not a lot I can do about that except try to track them down.
|
|
|
Samson
Evil Overlord
Group: Members
Posts: 2,631
Joined: May 13, 2006
|
#22 Posted Jul 18, 2009, 6:56 pm
|
Theodryck said:You yourself have been know to say so about glibc yourself, Samson. And glibc *does* give mud developers fits on a daily basis. It's open source and bound to have compatibility problems here and there.
I think perhaps you're confused as to which is which. glibc are the core system libraries. I've never complained about those, because none of the changes made to them have ever affected anything I do.
I have regularly complained about gcc/g++ and the GNU gang's incessant need to change the compiler at the drop of a hat causing untold grief as the world now needs to obey their newly imposed dictates. I don't think it's serving anyone to have them constantly making code breaking changes to that.
If valgrind is telling you there are uninitialized variables in your system libraries, something is wrong. It shouldn't be doing that. I've used valgrind a lot, and I've never once seen it complain about the system headers. Except in zlib, but I tossed in a suppression for that library. Maybe if you'd post some of what valgrind is telling you we could see what the real deal is?
|
|
|
David Haley
Wizard
Group: Members
Posts: 5,731
Joined: Jun 30, 2007
|
#23 Posted Jul 19, 2009, 9:40 am
|
Theodryck said:Still valgrind itself points to outside header files and not mud files as the source of my problems.
That could still be problems in your code: if you pass uninitialized variables to stdlib functions, the stdlib function will be where they're used, hmm...?
Let's put it this way: it is very unlikely that your crashes are caused by bugs in glibc. It is far more likely that your code is not using them correctly one way or another. If the stdlib was as buggy as you seem to think it is, well, let's just say that people would have noticed.
As Samson said, the best thing to do at this point is to show us examples of problems you're seeing.
|
|
|
elanthis
Wizard
Group: Members
Posts: 761
Joined: Feb 26, 2008
|
#24 Posted Jul 19, 2009, 2:38 pm
|
Theodryck said:I personally don't have anything against glibc as it relates to linux. But it's not even really needed for mud code and with all the new header files and library changes it makes it tough to sift through.
You, sir, have no idea what you're talking about.
Without libc, your MUD does not run. It cannot open sockets, it cannot send data to sockets, it cannot allocate memory, it cannot read files, it cannot do anything. Unless you're implying that you want to manually write the assembly code to invoke Linux syscalls instead of using the POSIX API, your MUD absolutely 100% definitely needs libc.
Quote:And glibc *does* give mud developers fits on a daily basis.
No. Poorly written MUD code gives MUD developers fits on a daily basis. If the code was written correctly in the first place, it would compile and run without problems on glibc or any other POSIX-compliant libc.
Quote:It's open source and bound to have compatibility problems here and there. That's the nature of the beast.
No. The fact that it's Open Source is irrelevant. The fact that glibc has been backwards compatible with Linux binaries and sources written over 15 years ago is relevant, and is more evidence that it's your code (or the code you inherited with the codebase) that is at fault.
Quote:Still valgrind itself points to outside header files and not mud files as the source of my problems.
Then either you installed your system incorrectly (you did do the sane thing and just used the distro RPMs for GCC and such, right?) or you're using them wrong. Garbage in, garbage out.
If the headers you're compiling against do not match the glibc binary you're linking against, it is possible to get some weird errors. When glibc does break ABI compatibility (long file support, for example), they use some tricks to ensure that old binaries keep working. This revolves around using versioned symbols and preprocessor and linker tricks to compile/link against the correct symbols. If your headers are for a newer version of glibc than you're linking against, it may be trying to link in improper ways.
Quote:We can toss this stuff back and forth all day but in the end I'm still stuck looking at my screen with valgrind telling me unitialized variables from ctypes.h or bits.h and etc. Those are included files with the gcc4 package. Not a lot I can do about that except try to track them down.
Can you actually post the Valgrind errors?
Also, is Valgrind installed by packages or by source? There are known "errors" in the libc headers (which aren't really errors, but Valgrind whines about them) that a proper Valgrind install is configured to ignore. If those are being shown for some reason -- possibly a bad install -- then you are chasing a red herring.
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#25 Posted Jul 19, 2009, 3:41 pm
|
elanthis said:You, sir, have no idea what you're talking about.
You must forgive Elanthis. He's cantankerous.
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
|
|
|
|
elanthis
Wizard
Group: Members
Posts: 761
Joined: Feb 26, 2008
|
#27 Posted Jul 19, 2009, 9:21 pm
|
Quote:You must forgive Elanthis. He's cantankerous.
Yeah, sorry. I went to the clinic and got a cream for it, should be all cleared up in about a week.
|
|
.........................
Cutting corners to keep your line count down is just sad.
|
|
|
|
