How To Solve throw std::bad_alloc{};?

Hello Professionals,

Good day. I would like to ask if there's any way I can get rid of
throw std::bad_alloc{};?

1
2
3
4
5
6
7
8
9
10
11
12
13
#else // ^^^ Managed ^^^ // vvv Native vvv //

    __declspec(noreturn) void __CRTDECL __scrt_throw_std_bad_alloc()
    {
        throw std::bad_alloc{};
    }

    __declspec(noreturn) void __CRTDECL __scrt_throw_std_bad_array_new_length()
    {
        throw std::bad_array_new_length{};
    }

#endif 


Every time I try to increase my cell values I input in my GLM function, it turns out to be bad alloc. I would like to know if there's a way I can resolve it?

Thank you very much for your inputs!
Last edited on
not sure what kind of answer you are expecting
the code would not just happily throw exceptions, so in order to solve it you need to analyse why do you keep reaching this situation over and over again.
It's like saying "my function is always returning early; here is the relevant code":

 
    return;

It's also tricky whenever I run the code myself.
It's kind of a tradeoff.
Whenever I increase the resolution of my 3D object, for instance,
if I use, 50x50x50, then it works fine, but, if I will use 60x60x60, it suddenly stops and
gives me the bad::alloc.
On the flip side, this resolution value also changes depending on the OBJ file I am using...
Show the code where you allocate whatever it is you're allocating.
I would like to share the excerpts of my program:

1
2
3
4
5
6
7
8
9
10
11
std::vector<float> phi;
std::vector<float> lambda;
std::vector<float> indCoordinates;
std::vector<float> g_Cen;
std::vector<float> g_CenIndex;

// User specific parameters
const std::string fName = "fox.obj"; // OBJ file
const glm::ivec3 g_numDiv = glm::ivec3(50, 50, 50); // Number of division
const int g_numMC = 200; // Number of division for marching cubes
const float g_distRatio = 0.01f; // Ratio of the width of the domain 


I also tried to print the max.size of my std vectors, and this is what I got:

phi.max_size()  1073741823
lambda.max_size()   1073741823
indCoordinates.max_size()   1073741823
g_Cen.max_size()   1073741823
g_CenIndex.max_size()   1073741823
Last edited on
You're not allocating anything there (other than the string fName). That's just where you declare your vectors. I assume there's some place where you're doing something like
 
some_vector.resize(60*60*60);
or something like that. Show the code around that.
I see. Okay, I will share the snippets of my code where "resize" exists:

1
2
3
4
5
6
7
8
9
10
11
12
	//////////
	// Start step 0 (Preprocessing)
	// Give seven normals to each triangle
	//////////
	g_objTriNorm.resize(g_objTri.size()); // Memory allocation
	std::cout << "g_objTri.size()" << g_objTri.size();
	for (unsigned int i = 0; i < g_objTri.size(); i++) {
		g_objTriNorm[i].resize(7); // Memory allocation for seven normals of i-th triangle
		glm::ivec3 ind = g_objTri[i];
.
.
.


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
	// Generate polygon using marching cubes
	CIsoSurface <float> *ciso = new CIsoSurface <float>();
	ciso->GenerateSurface(mcSamp.data(), 0.0f, g_numMC, g_numMC, g_numMC, hx, hy, hz);

	// Retrieve the result of marching cube
	g_mcVert.resize(ciso->m_nVertices);
	for (unsigned int i = 0; i < ciso->m_nVertices; i++) {
		g_mcVert[i] = glm::vec3(ciso->m_ppt3dVertices[i][0],
			ciso->m_ppt3dVertices[i][1], ciso->m_ppt3dVertices[i][2]);
		g_mcVert[i] += g_minCorner;
	}
	g_mcTri.resize(ciso->m_nTriangles);
.
.
.


ADDED....

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
	// Start marching cubes
	std::cout << "Start marching cubes..." << std::endl;
	timerS = std::chrono::high_resolution_clock::now();

	// Sampling of the function f(x, y, z) at grid points
	std::vector<float> mcSamp; // Vector to store function values at grid points
	mcSamp.resize((g_numMC + 1) * (g_numMC + 1) * (g_numMC + 1));
	float hx = g_bWidth.x / (float)g_numMC;
	float hy = g_bWidth.y / (float)g_numMC;
	float hz = g_bWidth.z / (float)g_numMC;
	for (int i = 0; i <= g_numMC; i++) {
		for (int j = 0; j <= g_numMC; j++) {
			for (int k = 0; k <= g_numMC; k++) {
.
.
.
Last edited on
Well, I can't see anything there. The snippets are out of context, so I can't tell the value of anything.

Do this: run your program through a debugger and let it crash. When it crashes, the debugger will highlight the point where the exception was thrown. The debugger should have a way to let you see the call stack. The call stack will look something like

<standard library implementation>
<standard library implementation>
<standard library implementation>
<standard library implementation>
your_code.cpp: 58
your_code.cpp: 64
your_code.cpp: 16
etc.

where the numbers after the colon are line numbers. The debugger should let you jump to those places (e.g. if you're using a GUI, by double-clicking those lines in the call stack). In the example above, the most interesting stack frame is your_code.cpp, line 58, because in all likelihood that's the immediate source of the error.
Find that line in your source and post the code around that line.

To clarify: I don't want you to post line 58 of your code. I want you to run your code through a debugger and find which line in your code is the immediate source of the error.
Thank you very much for your detailed information, though I must admit it's pretty new and hard for me to detect the error. I would like to verify if I'm doing the right thing before I move forward to the next step...

When I try to let my program crash, here's what I got from the "call stack" (I took a screenshot of the first scenario like the ones you mentioned in "your_code.cpp: 58" to make sure I don't miss any details):

1. [Inline Frame] Tani and Gerald's Method.exe!std::_Allocate(unsigned int) Line 78

https://i.imgur.com/3ytXEPD.png

Question: Does it mean the size of vector array is too big?

Note: I also updated the resize codes I pasted above with other vectors where I used resize. Maybe it could shed some light, I am not sure... Also, I found this code from this link:
https://github.com/icestudent/vc-19-changes/blob/master/xmemory0
and I was wondering if it would be helpful to use this and replace the current code in the xmemory0?

I also would like to ask if does it really matter if I use resize or not? If I remove it and just rely on the push_back, will it be a big problem?
I also tried to print the max.size of my std vectors, and this is what I got:
This is 1 Gigabyte per vector. All together 5 GB+. Too much?

I also would like to ask if does it really matter if I use resize or not? If I remove it and just rely on the push_back, will it be a big problem?
It certainly has a problem timewise because the reallocation occurs by far more frequently.
Topic archived. No new replies allowed.