problem when moving from 32 to 64 platform

[Cplusc]

I'm having difficulties when changing from 32 to 64. every single line of the code gives me an error. for example the following function works well in 32 but for the same function in 64 the code was abrobted;

inline void _Container_base12::_Orphan_all() noexcept
	{	// orphan all iterators
 #if _ITERATOR_DEBUG_LEVEL == 2
	if (_Myproxy != nullptr)
		{	// proxy allocated, drain it
		_Lockit _Lock(_LOCK_DEBUG);

		for (_Iterator_base12 **_Pnext = &_Myproxy->_Myfirstiter;
			*_Pnext != nullptr; *_Pnext = (*_Pnext)->_Mynextiter)
			(*_Pnext)->_Myproxy = nullptr;
		_Myproxy->_Myfirstiter = nullptr;
		}
 #endif /* _ITERATOR_DEBUG_LEVEL == 2 */
	}

the function:

void Variables_Initialization() {

	rhs_p_loc_.resize(nNodes_global_);
	P_[_x].resize(nNodes_global_);
	P_[_y].resize(nNodes_global_);

	for (int dim = 0; dim < _dim; dim++) {
		Velocity_[dim].resize(time_step_);
		GradP_[dim].resize(time_step_);
		for (int time_step = 0; time_step < time_step_; time_step++) {

			Velocity_[dim][time_step].resize(nNodes_global_);
			GradP_[dim][time_step].resize(nNodes_global_);
		}
	}
}

size_t nNodes_global_=100;
vector<vector<double> >GradP_[2]
vector<vector<double> >Velocity_[2]
dim=2;
time_step_=2;

[lastchance]

@cplusc, why don't you show us a simple small, self-contained piece of compileable code that runs on your 32-bit machine and not on your 64-bit one.

Nobody has any hope of compiling and running your snippets above.

[Ganado]

You should also explain what compiler/version you're using, and show the end result command-line being generated. It looks like you're looking into the internals of one of the Visual Studio container headers? You also didn't say what the error message was. It's probably more of an environmental/configuration issue than a code issue.

Edit: I was assuming this was a compiler error. But now I see you said it was aborted, so I'd go with what helios said.

[helios]

Unless one of those values that are being passed to std::vector::resize() is uninitialized, I would guess that the program corrupted the heap at some earlier point, in which case the fact that it crashed here doesn't tell you anything about where the bug actually is. You'll need to comb through the entire program looking for where you might be reading or writing things out of bounds, or use a memory debugger like Valgrind.

PS: It's probably just a coincidence that the bug is triggered when you compile for x86-64. It's quite likely that you would have run into the same issue if you, for example, tried building the program with a different compiler, or slightly different compiler flags.

[Cplusc]

@lastchance

#include <iostream>
#include "vector"

typedef std::vector<int>                VecInt_t;


typedef std::vector<size_t>             VecIdx_t;
typedef std::vector<VecIdx_t>           VecVecIdx_t;
typedef std::vector<VecVecIdx_t>        VecVecVecIdx_t;
typedef std::vector<double>             VecDbl_t;
typedef std::vector<VecDbl_t>           VecVecDbl_t;
typedef std::vector<VecVecDbl_t>        VecVecVecDbl_t;


void Variables_Initialization(VecDbl_t &rhs_p_loc_,VecVecDbl_t &P_,VecVecVecDbl_t &Velocity_, VecVecVecDbl_t &GradP_) {

	size_t nNodes_global_ = 100;
	size_t _x = 0;
	size_t _y = 1;
	size_t _dim = 2;
	size_t time_step_ = 2;

	rhs_p_loc_.resize(nNodes_global_);
	P_.resize(time_step_);
	P_[_x].resize(nNodes_global_);
	P_[_y].resize(nNodes_global_);
	Velocity_.resize(_dim);
	GradP_.resize(_dim);

	for (int dim = 0; dim < _dim; dim++) {
		Velocity_[dim].resize(time_step_);
		GradP_[dim].resize(time_step_);
		for (int time_step = 0; time_step < time_step_; time_step++) {

			Velocity_[dim][time_step].resize(nNodes_global_);
			GradP_[dim][time_step].resize(nNodes_global_);
		}
	}
}

int main()
{
	VecDbl_t rhs_p_loc;
	VecVecDbl_t P;
	VecVecVecDbl_t Velocity;
	VecVecVecDbl_t GradP;
	Variables_Initialization(rhs_p_loc, P, Velocity, GradP);

	return 0;
}

this piece of code is working in both 32 and 64. it's almost the as first snippest, but why the first one doesn't work in 64 bit?

[Cplusc]

@Ganado
my problem with 64 started with two errors, "The code execution cannot proceed because dll was not found" and "the application was unable to start correctly 0xc00007b". then I tried many things to fix this. now I am afraid maybe I changed some configurations which cause these kind of problems. Almost in any simple code I have problem when moving from 32 to 64.

[Cplusc]

@helios
all variables are initialized. There is no earlier point. the rest of the code is commented. just this single function is called.

[lastchance]

Cplusc wrote:

this piece of code is working in both 32 and 64

That isn't much help then. Show us some code that does NOT run on a 64-bit platform.

That complete code compiled and ran without errors with both g++ and cl.exe compilers on my 64-bit operating system, compiled for default (64-bit).


Your posts aren't clear.

- IF that code RUNS on your 64-bit machine then it is likely that there is an out-of-bounds or undefined-variable error in your larger code which you happened to get away with in 32-bit.
- If that complete small code did NOT run on your 64-bit machine then you have an IDE/compiler configuration error.

Please clear up whether that last, complete code did or did not run on your 64-bit machine.

[seeplus]

The code execution cannot proceed because dll was not found

Both the exe and any used .dll must be the same - all 32 bit or all 64 bit. You can't mix 32 bit with 64 bit.

[Cplusc]

@seeplus
Both exe and del in both 32 and 64 are the same. They're mixed.

[lastchance]

Cplusc wrote:

Both exe and del [sic] in both 32 and 64 are the same. They're mixed.

What???


Let me repeat my question (referring to the code https://www.cplusplus.com/forum/general/282252/#msg1221367 )

Please clear up whether that last, complete code did or did not run on your 64-bit machine.

Please answer coherently.

[Cplusc]

@lastchance
How it comes that this error does not appear in the 32 but shows itself in 64? It's because of the difference in variable size in the two platforms?

[lastchance]

@Cplusc,
Please answer my question and stop making the thread ever more incoherent!


An error because of attempted access outside array bounds may not actually cause the code to crash in one case, say 32-bit - but it will still be an error. That error may, however, cause the code to crash in 64-bit, simply because of a different layout of memory.

You need to post some standalone, compileable and runnable code that you claim runs on 32-bit but not 64-bit. We can't reproduce your problem without it.


Your answers are so confusing that we can't even tell if a simple "Hello, world" program runs on your 64-bit machine.

[Cplusc]

in privoius answer there was a typo. THEY ARE NOT MIXED. BOTH THE EXE AND ANY USED .DLL ARE THE SAME - ALL 32 BIT OR ALL 64 BIT.
A simple "hello world" will run on both 32 and 64.
ok,Let me provide one stand alone compateable code, I'll post in this tread.
for some small codes, the code run on 64-bit machine but in some other it gives me an error "heap corruption detected after normal block c++(#151) at 0*001E3518.CRT detected that the application wrote to memory after end of heap buffer"

[Ganado]

Probably going out of bounds of a heap-allocated object.

[seeplus]

Could be because for 32 bit sizeof(int) is usually the same as sizeof(int*) which isn't true for 64 bit. There could be an allocation issue somewhere not allocating enough memory.

[deleted account xyzzy]

Are you using pointers? 32-bit pointers are NOT the same size in 64-bit.

[lastchance]

Ganado wrote:

Probably going out of bounds of a heap-allocated object.

I'm inclined to agree.

Looking at the variable-naming convention in the code snippet given, the addition of a single '_' to the end of an index would produce compileable code but would attempt access beyond the array.

@Cplusc, please turn the debugger on. If you are doing it from the command line then just
cl /EHsc /Zi temp.cpp
then
gdb temp.exe (and run)
Adding the line
GradP_[1][1][nNodes_global_] = 1.0;
to your working code would soon crash it and produce a comparable error report.

[Cplusc]

@seeplus
if this is the case (which I think it it). Waht should I do to fix this, changing the variable type can help? I have lots of size_t variables in my code which On a 32-bit system size_t will take 32 bits, on a 64-bit one 64 bits. even this makes problem for my MPI. becuase in this case there will be a problem when receiving data and not having enough space for that.

[lastchance]

@Cplusc, the size of the variable is irrelevant. 64-bit machines are perfectly capable of storing 4-byte integers. The red herring was pointers. You aren't kicking pointers around in MPI.

Work on producing a simple but complete piece of code for us.

(And turn the debugger on!)