UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

  • Index
  • » C++
  • » Memory corruption on Solaris based C++ project

#1 2008-01-05 07:32 AM

acmbtcs
Member
Registered: 2008-01-05
Posts: 4

Re: Memory corruption on Solaris based C++ project

Offline

#2 2008-01-05 03:11 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Memory corruption on Solaris based C++ project

Can you try to run it on another platform? It would be interesting to know whether
it works somewhere else, and running it through Valgrind might be helpful too.
Though this is only helpful if it doesn't work somewhere else either.

The strcpy you're doing has no length checks, so you're sure it doesn't overrun?
Perhaps not this one, but a similar unbounded string operation somewhere else?

To rule out inheritance/overloading stuff, does it also happen when you change the
function name?

And also doublecheck if the c++ compiler and libraries used for the RW libs are
compatible with the one you're using.

Offline

#3 2008-01-05 06:53 PM

acmbtcs
Member
Registered: 2008-01-05
Posts: 4

Re: Memory corruption on Solaris based C++ project

Offline

#4 2008-01-05 07:10 PM

jfriesne
Administrator
From: California
Registered: 2005-07-06
Posts: 348
Website

Re: Memory corruption on Solaris based C++ project

This is probably too obvious a suggestion to be helpful, but have you tried printing out the pointer values that you are passing in to strcpy(), as well as strlen(tV), and seeing if they are reasonable values or not? 

printf("about to strcpy, from=%p to=%p len=%i\n", tV, vA, strlen(tV));

Another thing you might try is to disable optimization when compiling (-o0 ?) and see if that makes the problem go away.  If it does, it would suggest a bug in your compiler's optimization code....

Offline

#5 2008-01-05 07:11 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Memory corruption on Solaris based C++ project

Valgrind doesn't run on MIPS Solaris I'm afraid.

Anyway, did you add some debugging code to setVa() yet? Doing a strcmp between
vA and tV after the assignment would be interesting. What value has the garbage
char, and is it always the same? (Each run, after each assignment, even with
different tV etc.)

I suspect that that garbage char at the start is present in tV too, or an overflow
happens somewhere else. A strcpy without bound check and variable length strings
as input is a plain bug, is there nothing guaranteeing that tV is never longer than
fits into vA? Same for other places you do strcpy or similar things.

Best would to trip your program down chunk by chunk until you pinpoint where
it goes wrong or until you have a very minimal testcase that inhibits the bug.

(Edit: Ok, now I know how you guys feel when I sneak in... ;-)

Offline

#6 2008-01-06 12:14 PM

acmbtcs
Member
Registered: 2008-01-05
Posts: 4

Re: Memory corruption on Solaris based C++ project

Offline

#7 2008-01-06 02:14 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Memory corruption on Solaris based C++ project

First thing I'd try is doubling the size of vA, just to see what happens.

Do you ever modify the value after inserting it in the vector? That could mess things
up. Try removing it before editing it, and afterwards re-inserting it.

And is vA a RWCollectableString? Or is class A already a collectable and you add it
to the vector, not vA directly?

Offline

#8 2008-01-06 07:30 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,839
Website

Re: Memory corruption on Solaris based C++ project

I'd throw lots of debugging printf()'s (or logging to some file, if output to screen is
infeasable) into that setVa() function...  In addition to the pointers and source strlen()
that jfriesne suggests, I'd also output the entire source string (to make sure that the
correct 0th byte isn't actually coming from the source string somehow), and maybe
dump the entire contents of the "vA" buffer both before and after the strcpy()...  I
know you said you're printing this elsewhere, but I'd do it right there in the set function,
to make sure that that is truly where the corruption is occuring...  If you don't see any
corruption in there, then you can safely assume it's happening elsewhere, and you're
focused on the wrong spot in the code...  Also, print out the pointer values of both
"vA" and whatever that source "tV" string really is that's passed to setVa() outside of
the function, eg. just before you call the function...  Then, compare those with the
values of the pointers seen by the function itself...  Because, it sounds like somehow
you're going one byte off in one of the references, somehow...  I'm not sure how,
if it's not some strange compiler optimization bug (which you apparently ruled out)...

The next step I'd do, if the above showed the corruption actually occurring within
the setVa() function (ie: a dump of "vA" immediately after the strcpy() shows the
corrupt 0th byte, yet the source string does NOT have that corrupt 0th byte), is
replace the strcpy() with a hand-rolled version, and see if that fixes things...  I
suppose it's possible your libc's strcpy() is busted in some strange way, though I'd
find that highly unlikely...

Offline

#9 2008-01-07 02:18 AM

jfriesne
Administrator
From: California
Registered: 2005-07-06
Posts: 348
Website

Re: Memory corruption on Solaris based C++ project

Offline

#10 2008-01-07 05:42 PM

acmbtcs
Member
Registered: 2008-01-05
Posts: 4

Re: Memory corruption on Solaris based C++ project

hi Guys, thanks again.
i3839,
I would try doubling, answer to your next question is NO, once into the vectore it is only read, vA is a simple charater array while the class is already a collectable.
Rob,
I had tried a log of printf's and stubs just to make sure that there was no corruption with in the function( well actually i put in a lot of out lines in all the set functionalities). I agree with you 100% on the 1 byte off on the variable. but what puzzles me is why?? why our memory analyzers like purify don't pick it up.
jfrie,
Thank you for explaining, I din't quite think like that. I guess I will try that tommorow.

Thanks and regards
Arun

Offline

#11 2008-01-07 06:10 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: Memory corruption on Solaris based C++ project

Because you're accessing valid memory, so it's still a valid memory address and they
see nothing wrong. You could try making vA one or two bytes big and stuff zero or
only one char in it (if that's possible with your code), and then it will probably pick
something up, if it's as good as Valgrind.

It seems you're nearing the dreaded "clash code chunks away till the minimal base
is left" to pin it down. Or post code, perhaps we see something wrong.

Offline

#12 2008-01-07 08:02 PM

RobSeace
Administrator
From: Boston, MA
Registered: 2002-06-12
Posts: 3,839
Website

Re: Memory corruption on Solaris based C++ project

You say you added some debug logging, but I'm unclear on what the results were?
Did the pointer values look correct (ie: not one byte off from where it should be)?
Did the corrupt 0th byte appear immediately after the strcpy() within the set function?
If so, like I say, maybe try replacing strcpy() with your own code, just to eliminate the
possibility of a broken strcpy() (even though I'd find that a very unlikely possibility)...
Just something simple like:

char *src, *dst;

for (src = tV, dst = vA; *src; src++, dst++)
    *dst = *src;

If the corruption is still present immediately after THAT, then add debugging code
to the loop to print out each byte after it's assigned (both the source and destination
values)...  Chances are, the source pointer must be corrupt and one byte less than
its proper location, in that case, so that the "corrupt" 0th byte is really coming from
there and being copied properly...  So, you'd need to look into how it's being called,
and the specific arg passed, in that case...

Offline

#13 2008-01-07 10:28 PM

mlampkin
Administrator
From: Sol 3
Registered: 2002-06-12
Posts: 911
Website

Re: Memory corruption on Solaris based C++ project

Just a couple quick observations / comments:

* you do need the from string to be null terminated or you will get an overrun...

* a lot of debuggers ( not certain about Purify ) have issues catching the above error and this partially an artifact of how the compilers sometimes 'optimize' the function e.g. see the gcc / solaris _built_in ( I think thats it ) docs etc. ...

* considering you mentioned the 'flipped' characters it almost sounds like one of the strings / char *'s is actually pointing to a wchar or similar type - btw - with your 'hello' string example - what are the 'junk' characters etc. ?

* why oh why are you programming in C++ yet using C style strings and pointers... if you really need ptrs (?!) make the param tV a const char * at the very least... :(


Michael


"The only difference between me and a madman is that I'm not mad."

Salvador Dali (1904-1989)

Offline

  • Index
  • » C++
  • » Memory corruption on Solaris based C++ project

Board footer

Powered by FluxBB