帮助解决此断言失败错误 [英] Help to solve this assertion failed error

问题描述

http://s1.uploads.im/vVqAx.png



我想知道如何解决这个奇怪的断言失败。这是我的程序..

http://s1.uploads.im/vVqAx.png

I want to know how to solve this strange assertion fail. This is my program..

#include <iostream>

using std::cout;
using std::endl;

void eatSpaces(const char arr[]);

void main()
{
	char x[]{"hello world how are you"};
	eatSpaces(x);
}

void eatSpaces(const char arr[])
{
	size_t arrPosition{}, strPosition{};
	char* str = new char[];
	
	while (arr[arrPosition] != '\0')
	{
		if (arr[arrPosition] != ' ')
			*(str + strPosition++) = arr[arrPosition];

		arrPosition++;
	}
	*(str + strPosition) = '\0';

	cout << str << endl;
}

如你所见，我的程序与文件 f：\dd\vctools\crt\crtw32 \misc \ dbgheap.c

除了它不是我保存程序的地方..它是可移动的设备。为什么这些错误没有任何明确的原因发生



此消息框不会立即出现..它就像一个随机的..有时程序编译并运行没有错误。但有时当程序打开时，这个断言失败就会出现。



提前致谢！



PS：无论我拔掉设备，这个消息框不断显示。

As you see, my program has nothing to do with the file "f:\dd\vctools\crt\crtw32\misc\dbgheap.c"
Besides it's not where I save my programs.. It's a removable device. Why such errors occur without any clear reason ?

And this message box doesn't show up at once.. It's like a random.. Sometimes the program compiles and run with no errors. But sometimes as the program opens this assertion failing shows up.

Thanks in advance !

PS: No matter if I unplug the device, this message box keep showing up.

推荐答案

hi，

欢迎来到堆损坏，内存泄漏和事后转储的世界分析。

您需要使用WinDbg来解决此类问题。



Actualy，您的应用程序正在泄漏内存。那么，什么是内存泄漏 [ ^ ]



如果谷歌用于dd / vctools / crt / crtw32 / misc / dbgheap.c，您将看到它是内存泄漏的一般错误消息。它与保存程序的位置无关。



您需要将应用程序附加到WinDbg然后执行它。

你可以直接看到调用堆栈。这称为实时调试。

或

在您的情况下，我认为必须自动生成内存转储。您可以分析此转储

以查看导致错误的代码行。 '原因'会变得非常清楚;）



我不想给你过量的信息，以防所有这些对你来说都是新的。最好慢点并尝试学习这些有用的技能。



有用的系列与WinDbg相关的文章 [ ^ ]

你可以谷歌更多的WinDbg，转储文件，pdb文件等。



希望这是很有帮助！

Welcome to the world of heap corruption, memory leaks and postmortem dump analysis.
You need to use WinDbg for such issues .

Actualy, your application is leaking memory . So,what is a memory leak[^]

If you Google for "dd/vctools/crt/crtw32/misc/dbgheap.c", you will see that it is a general error message for memory leak . It has nothing to do with where you save your programs.

You need to attach your application to WinDbg and then execute it.
You can directly see the call stack. This is called live debugging.
OR
In your case i think a memory dump must be generated automatically. you can analyze this dump
to see which line of code is causing the error . the 'reasons' will become pretty clear ;)

I do not want to give you overdose of info, in case all these things sound new to you. Better go slow and try to learn these useful skills.

Helpful series of articles related to WinDbg[^]
You can google more for WinDbg, dump files, pdb files etc .

hope this was helpful!

char* str = new char[];

此分配没有多大意义，我'我很惊讶编译器在没有警告或错误的情况下吃掉它。您尚未指定数组长度，因此您分配的内存可能只有1个字节。如果你想要更多，你需要传递所需的长度作为参数。你以后访问str访问未分配的内存，导致错误。

This allocation doesn't make a lot of sense and I'm surprised the compiler eats it without a warning or error. You haven't specified an array length, so your allocated memory may be as little as 1 byte. If you want more than that, you need to pass the required length as argument. Your later access to str accesses unallocated memory, causing the error.

有几个选项;但是这个程序的基本结构正确地改变了这种可能性。

有几个因素可以帮助我们找到问题出现的地方;这些问题需要回答。

自上次编译二进制文件以来，您是否更改了源代码？

您的应用程序是否生成工作线程？

你有没有正确平衡所有运算符new（）/ malloc（）/ operator new []（）调用相应的delete，free（）或delete []？

你有没有适当地设置null所有无效的悬空指针（在删除或RAII样式解除分配后）？

在编译过程中，任何编译都失败并出现相同的错误，只是神奇地消失而基本没有变化？



堆断言检查pUserData是指向堆内存的有效指针的假设。

不是。从那里开始;中断并使用调用堆栈查找变量更改的最后一个点。在变量上设置一个新的数据断点。





如果您的程序涉及线程：检查所有同步。

如果您的程序源已被更改，请检查您的SCC差异以查看您所做的更改。

但可能的错误是您刚刚损坏了指针。

你应该责怪每个为这个变量编写动态内存的人。在开始寻找其他标准之前检查一下。

There's a couple options; but the likelihood of diagnosing this correctly changes dramatically with the underlying structure of this program.
There's a couple of factors that will help us find where the problem arises; these questions need answering.
Have you changed the source at all since you last compiled the binary?
Does your application generate worker threads?
Have you correctly balanced all operator new()/malloc()/operator new[]() calls with the appropriate delete, free() or delete[]?
Have you appropriately set null all invalid dangling pointers (after delete or a RAII style deallocation)?
During your compilation process, did any compilations fail with the same error, only to magically disappear with basically no change?

The heap assertion checks the assumption that pUserData is a valid pointer to the heap memory.
It is not. start from there; break and use the call stack to find the last point the variable changed. Set a new data break-point on the variable.


If your program involves threads: check all your synchronization.
If your program source has been changed, please check your SCC's diff to see what change you made.
But the likely error is that you've just corrupted the pointer.
You should blame everyone who writes dynamic memory to this variable. Check this before you start looking for other criterion.

这篇关于帮助解决此断言失败错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！