views:

83

answers:

3

I have some software that I have working on a redhat system with icc and it is working fine. When I ported the code to an IRIX system running with MIPS then I get some calculations that come out as "nan" when there should definitely be values there.

I dont have any good debuggers on the non-redhat system, but I have tracked down that some of my arrays are getting "nan" sporadically in them and that is causing my dot product calculation to come back as "nan."

Seeing as how I can't track it down with a debugger, I am thinking that the problem may be with a memcpy. Are there any issues with the MIPS compiler memcpy() fucntion with dynamically allocated arrays? I am basically using

 memcpy(to, from, n*sizeof(double));

And I can't really prove it,b ut I think this may be the issue. Is there some workaround? Perhaps sme data is misaligned? How do I fix that?

A: 

Is sizeof() definitely supported?

Andrew
Yes. It returns 8 on this system
Derek
+1  A: 

I'd be surprised if your problem came from a bug in memcpy. It may be an alignment issue: are your doubles sufficiently aligned? (They will be if you only store them in double or double[] objects or through double* pointers but might not be if you move them around via void* pointers). X86 platforms are more tolerant to misalignment than most.

Did you try compiling your code with gcc at a high warning level? (Gcc is available just about everywhere that's not a microcontroller or mainframe. It may produce slower code but better diagnostics than the “native” compiler.)

Of course, it could always be a buffer overflow or other memory management problem in some unrelated part of the code that just happened not to cause any visible bug on your original platform.

If you can't get a access to a good debugger, try at least printf'ing stuff in key places.

Gilles
I will check to see if gcc is on there. I doubt it is, as this is a pretty much purpose-built system. Didnt realize it might have more warnings than another.They arrays are defined as double * If I used something like totalview on the original platform and turned on memory debugging, it should still give me an answer w.r.t. buffer overflows and such right? Maybe I will give that a try, even though its giving correct answers there
Derek
@Derek: Yes, trying something like totalview or valgrind (which is free and has a good reputation) is a good idea, and it might find bugs even on the original platform. It's not guaranteed to find the bug (if any), but it's usually worth the time trying.
Gilles
That's my bet -- that the destination is not properly aligned, so while the memcpy works, accessing the data after is not expecting unaligned data.
nategoose
Turns out after running this with totalview, i still couldnt find a memory out of bounds condition or anything. By dumb luck I put in a print statement in a couple of places and this was the issue - overflowing the space by 1. Must be luck that it worked on the intel system.
Derek
+1  A: 

Is it possible for the memory regions to and from to overlap? memcpy isn't required to handle overlapping memory regions. If this is your problem then the solution is as simple as using memmove instead.

torak
i will keep this in mind for future reference
Derek
+1 for the idea, even if it wasn't the problem in this case.
Steve Jessop