Language:
switch to room list switch to menu My folders
Go to page: First ... 101 102 103 104 [105] 106 107 108 109 ... Last
[#] Mon Aug 04 2014 23:09:06 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


not sure what you're using valgrind for - either it's leak tracing, or heap overrun debugging, or something else that overlaps with some othe r tools out there.

there are many tools that COULD MAYBE be used to analyze heap overruns or leaks, including but not limited to:

* taking your binary, compiled for some ancient system, and running it on a more modern system where newer tools are functional
* The BSD "dbx" debugger is available for Linux from http://www.oracle.com/technetwork/server-storage/solarisstudio/overview/index.html and includes a check leaks mode: see http://www.oracle.com/technetwork/java/javase/memleaks-137499.html#gbyza for a JVM-centric example on leak checking. I have had mixed results with this. It looks promising, but tends to freeze the JVM. Simpler programs may have less problems - the JVM does a lot of low-level tricks.
* libumem, if you happen to have access to a Solaris box
* libnjamd - used to exist on Linux, seems to be dead and unsupported now

* libefence - ElectricFence library. The classic on linux until valgrind. Can be useful for both leaks and heap boundaries
* libduma - This is a fork of libefence, also works on windows, might be more widely distributed these days on Linux
* glibc's own facilities include mtrace, MALLOC_CHECK_, __malloc_hook, mcheck, and various environment hooks to the same. mtrace may not be thread-safe(?)



all of these tools have problems, none are perfect, the way I see it.

[#] Tue Aug 05 2014 02:25:15 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

valgrind memcheck also gives you checks for uninitialized access on values - which is quiet usefull to find situations where if's do random stuff.

however, its got the biggest performance overhead.

tcmalloc not only promises to be faster than libc's malloc, it also has some heap profiling stuff & double free checks etc - however it dosn't deliver estimates where the mem you access was free'd in advance.



[#] Tue Aug 05 2014 08:44:55 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


If I compile a binary on an ancient system, then move that binary to a modern system, wouldn't it have other problems? I thought Linux didn't really support that level of upward compatibility.

Valgrind at least helped me zero in on the lines of code where problems manifested.
Oddly, it seemed to interpret the debugging symbols better than gdb.

I do have access to a Solaris box, but it's similarly ancient. And, yeah, I have to try to support the damned thing. I must say, when you're forced to work with extremely old versions of operating systems, you learn a lot about the operating system. It might be a trial by fire, but this kind of study is like a crucible for learning more about flavors of posix-oriented operating systems.

I'm blaming the compiler. The product works properly on other environments, just not this old thing with the dubious compiler. I think, before I spend too much time investigating this further, I should consider compiling the oldest compiler that works with our product, and use that for building the system. Hopefully, *that* compiler will be old enough that the OS won't object to it (that is, that I won't have to make any alterations at all just to get the compiler to build properly).

[#] Tue Aug 05 2014 12:17:01 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

If I compile a binary on an ancient system, then move that binary to a

modern system, wouldn't it have other problems? I thought Linux didn't

really support that level of upward compatibility.

If all it needs is libc & libcstd++ it should work OK. Compatibility with the system would be fine - compatibility with the debugging tools is another question entirely.

So it depends on your library dependency footprint.

[#] Tue Aug 05 2014 12:19:27 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I'm blaming the compiler. The product works properly on other
environments, just not this old thing with the dubious compiler. I
think, before I spend too much time investigating this further, I
should consider compiling the oldest compiler that works with our
product, and use that for building the system. Hopefully, *that*
compiler will be old enough that the OS won't object to it (that is,
that I won't have to make any alterations at all just to get the
compiler to build properly).

I don't know, there could be binutils issues as well. Frequently newer GCC requires newer binutils, but then the output of the newer linker might have issues on the older kernel/ld.so/glibc stack. I
'm not really knowledgeable about those areas... if you can limit yourself to a gcc that works with the binutils that originally shipped on the system, you may have a better chance of success.

[#] Tue Aug 05 2014 12:20:34 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Oh, and binutils on Linux always been funky. Periodically, Ted T'so sends an announcement of "here is the latest version of The Linux Binutils", and the gcc folks duly complain "why are there so many patches against upstream?"

[#] Tue Aug 05 2014 14:03:56 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I did update the binutils, since the one on the system wasn't compatible with the updated compiler.

So, yeah, that's probably the problem.

I might be on the right track, then, with an older compiler. Hopefully, I can find one that's new enough for the code I use, yet old enough for this machine.

[#] Wed Aug 06 2014 11:44:28 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Ugh... this is like Goldilocks.

"And this compiler was *just* *right*."

The compiler, the compiler, the compiler is on fire!
We don't need no water -- let the motherfucker burn!
BURN, MOTHERFUCKER, BURN!

[#] Thu Aug 07 2014 11:16:07 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Should have written the application in Java. "Write once, run anywhere."
<grin>

[#] Thu Aug 07 2014 11:59:43 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


HA!

That's a joke.

I can't get Jenkin's client to run on this Valhalla Redhat machine because I can't install a new enough version of Java on it.

[#] Thu Aug 07 2014 13:38:54 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Valhalla, NY is just a couple of miles away from here. You want me to drive over and try it?

[#] Thu Aug 07 2014 16:22:44 EDT from vince-q @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

2014-08-07 13:38 from IGnatius T Foobar @uncnsrd
Valhalla, NY is just a couple of miles away from here. You want me to

drive over and try it?



If you were a god, I could suggest "Entrance of the Gods into Valhalla" as the accompanying music.... <evil grin>

[#] Fri Aug 08 2014 14:11:01 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Huh.

I am not sure if this is because of something special we're doing with LD_PRELOAD, but it looks like statically linking libs into your shared objects causes the shared object to no longer preload.

[#] Fri Aug 08 2014 17:39:15 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I am not sure if this is because of something special we're doing with

LD_PRELOAD, but it looks like statically linking libs into your shared

objects causes the shared object to no longer preload.

missing -fPIC?

[#] Mon Aug 11 2014 08:25:25 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Hmm... I'll look into that. That doesn't look familiar.

Fiddly, getting the right command line arguments.

[#] Mon Aug 11 2014 10:30:29 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


Hmm... I get why -fPIC is needed, and I suspect that's the problem.

Adding it, though, leads to several undfined symbols from C++ (e.g.: _Unwind_Resume).
I note these seem to be undefined within the C++ lib file, which suggests it expects *someone* to provide these, but I'm not sure who.

I could probably work around the problem by creating something to link into everything that just defines all of these as void*... but that feels wrong to me, like I'm missing something else to which I should pay attention.

Well, it's something with which to play.

[#] Mon Aug 11 2014 16:42:07 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I note these seem to be undefined within the C++ lib file, which
suggests it expects *someone* to provide these, but I'm not sure who.


libgcc_s I believe.

[#] Tue Aug 12 2014 08:37:59 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I did find it in libgcc_eh, which is hidden away in the bowels of the folders somewhere, but the compiler seems to defy including it.

I may try playing with this later. I have something that works, even if it isn't my ideal.

I think I've been trying to work through Linux issues for about a month now, when I was hired to work on Windows, just because the Linux guy we have doesn't seem eager, willing or perhaps capable of looking into this kind of stuff.
But I have a Windows bug I've discovered that I need to address... a nasty crash exposed by doing something our students will commonly do.

(And, yeah, I recognize the first problem is that they're using Windows, but this is a class... we sorta have to let them discover the ways in which Windows sucks, and you can't really do that without Windows).

[#] Tue Aug 12 2014 11:46:03 EDT from LoanShark @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I did find it in libgcc_eh, which is hidden away in the bowels of the

folders somewhere, but the compiler seems to defy including it.

think you need to link with g++ -shared in order for it to happen automatically.

[#] Tue Aug 12 2014 12:36:11 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]


I did try to link with g++ instead of gcc, but that lead to some other kind of problem... it complained that it could no longer find -lgcc_s, even when I went to the trouble of explicitly adding the path that it already knew about.

Go to page: First ... 101 102 103 104 [105] 106 107 108 109 ... Last