的libc检测*** ./textfileread.exe：realloc（）的：无效下一尺寸：0x08643008

我在主声明双指针和这样的libc检测*** ./textfileread.exe：realloc（）的：无效下一尺寸：0x08643008

char **group_name; 
group_name = realloc(NULL, 1); 
group_name[0] = realloc(NULL ,20);

我已经过了这个阵列的功能分配存储器，

group_count(object, count, group_name);

它使用realloc。它会罚款，直到它填充前四次重新分配，但在第五次，它会给出错误。

libc detected *** ./textfileread.exe: realloc(): invalid next size: 0x08643008 

int group_count(struct friends obj[], char cn, char **grp_nm) 
{ 
    int i=0,j=0; 
    int grp_cn=0; 
    char check=0; 
    strcpy(grp_nm[0],obj[0].group); 
    grp_cn++; 
    grp_count++; 

    for(i=1;i<cn;i++) { 
     for(j=0;j<grp_cn;j++) { 
      if(strcmp(grp_nm[j],obj[i].group)==0) 
       check=1; 
     } 
     if(check==0) { 
      grp_cn++; 
      grp_count++; 
      printf("\t%d\n",grp_cn); 
      grp_nm = realloc(grp_nm, grp_cn); //at grp_cn=5 allocation gives error 
      printf("\t%d\n",grp_nm); 
      if(grp_nm == NULL) printf("\t%d\n",grp_cn); // this 'if' didnt run, means no NULL return 
      grp_nm[grp_cn-1] = realloc(NULL ,20); 
      strcpy(grp_nm[grp_cn-1],obj[i].group); 
     } 
    check=0; 
    } 
}

printf（“\ t％d \ n”，grp_nm）的输出;下面给出，这之后再分配

2 
140783624 
3 
140783624 
4 
140783624 
5 

*** glibc detected *** ./textfileread.exe: realloc(): invalid next size: 0x099c8008  *** 
======= Backtrace: ========= 
/lib/i386-linux-gnu/libc.so.6(+0x6b961)[0x17b961] 
lib/i386-linux-gnu/libc.so.6(+0x6f1ad)[0x17f1ad] 
/lib/i386-linux-gnu/libc.so.6(realloc+0xe9)[0x180579] 
./textfileread.exe[0x804934e] 
./textfileread.exe[0x8048b42] 
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x126e37] 
./textfileread.exe[0x8048751] 
======= Memory map: ======== 
00110000-0026a000 r-xp 00000000 08:02 1570626 /lib/i386-linux-gnu/libc-2.13.so

的第五次迭代5后，在屏幕上输出，地址应显示为它显示4之后，但它没有，那么为什么在5给它的错误？

来源

2012-08-13 Haris_tech

你倒是应该用printf（ “％P”，grp_nm）用于显示指针。这将使用有意义的格式，避免有关ptr-to-int隐式转换的警告，并且如果碰巧在具有不同int /指针大小的系统上使用代码，则不会垃圾输出。 – PypeBros 2012-08-14 08:32:30

为什么要用realloc进行初始分配？

反正...

char **group_name; 
group_name = realloc(NULL, 1); 
// group_name is now pointing to 1 byte of dynamically allocated memory 
group_name[0] = realloc(NULL ,20); 
// Whoops. Did we just write 4(or more bytes) into our 1 allocated byte?

我觉得你的方法内部存在同样的问题。

来源

2012-08-13 05:35:37 John3136

realloc在与NULL一起使用时是malloc，这就是为什么。只是在代码中的相似性。 – 2012-08-14 05:33:46

最可能的问题是因为您在分配时使用了错误的大小。

char **group_name; 
group_name = realloc(NULL, 1);

但char **是不一个单字节，它的4个或8（取决于如果你是一个32位或64位平台上）。而是使用sizeof操作：

group_name = realloc(NULL, sizeof *group_name);

后来当您重新分配：

grp_nm = realloc(grp_nm, grp_cn * sizeof *grp_nm);

来源

2012-08-13 05:53:27

也许你的意思是'realloc（NULL，sizeof * group_name）;'不是吗？ – 2012-08-13 08:21:00

好吧，我会尝试一下，但据我所知，没有必要做sizeof，因为它的8位意味着1个字节。我在sizeof需要int或float类型的其他回复中查看，但不需要char。但是我会尝试并发布结果。 – 2012-08-14 05:36:40

@JensGustedt是的，你说得对。谢谢。 – 2012-08-14 06:03:12

你的问题的核心可能是你破坏簿记指针确定malloc与你一起新鲜套分配的块。当您将该“块”放回realloc时，它会尝试使用已损坏的指针在空闲区和其他类似活动中重新插入内存。

“为什么5而不是4”......很可能是因为realloc在此之前不需要使用之前返回的块之一（例如，因为您的块实际上比您要求的大，并且realloc认为您会没事的无需重新分配一些内存）。 malloc/free是一些复杂的软件，当错误使用时可能会显示出卡路里行为。

来源

2012-08-13 09:48:19 PypeBros

请ü可以解释，当我在我的代码做这个...“（例如，因为你的块，比你要求和realloc认为无需重新分配一些内存，你会没事的实际大）。” – 2012-08-14 05:38:19

的malloc具有粒度每个系统都有所不同，但通常在16个字节左右。 realloc（ptr，5），你是低于和分配块的大小（16字节）比你认为它的大小小。 – PypeBros 2012-08-14 08:30:38

joachim的答案很可能解释你如何修复你的代码。你还质疑“为什么用5 ...”，我认为更好地意识到分配器的内部工作是关键。 – PypeBros 2012-08-14 08:37:08

谢谢。它有帮助。

group_name = realloc(NULL, sizeof *group_name); 
    grp_nm = realloc(grp_nm, grp_cn * sizeof *grp_nm);

之后，libc错误完成。但有时我不能读取值在数组被填充子例程，即在main（）我不能读取值group_name [3]让我们假设。但子程序grp_nm [3]显示得非常好，因为我在子程序中传递了指向数组group_name的指针。我发现的原因是，在realloc期间，如果它与剩余内存冲突，它会将整个数组重新定义为新的位置，从而将指针更改为数组。例如，在主要组名= 0x5689F0 i之后将其传递到子程序，上第一重新分配grp_nm = 0x5689F0 上第二重新分配grp_nm = 0x5689F0

并且由于在阵列grp_nm的位置存储器冲突改变一些重新分配后将变成0x345FF1。所以我必须从子程序reuturn this指针像这样

 group_name=group_count(object, count, group_name);

，这样，如果指针的变化，它会被更新现在组名= 0x345FF1

来源

2012-08-16 18:54:12

的libc检测*** ./textfileread.exe：realloc（）的：无效下一尺寸：0x08643008

回答

相关问题