coredump 中的堆栈损坏?海湾合作委员会/c

发布于 2024-10-18 21:45:54 字数 1541 浏览 0 评论 0原文

当我尝试使用信号处理程序将全局数据转储到文本文件并生成核心文件时,我注意到一个奇怪的问题。 的核心文件中存在的数据相同(它是相同的全局数据)。

文件的数据与标头文件 foo.h

extern char buffer[100][80] ; // Hundred records each of length 80 characters

中 foo.c

char buffer[100][80];

.. in a loop ..
snprintf(buffer[i],80,"%s:%d recorded idx = %d\n",__FUNCTION__,__LINE__,i);

中 signal_handler.c 中

.. in a loop ..
fprintf(..dump data to text file..)

我希望转储到 文本文件好吧。我在 gdb 中运行该程序,并通过 Kill 发出 ABRT 信号(我正在处理的信号)。在 gdb 中,我看到

gdb) p &buffer[0]
$3 = (char (*)[80]) 0x1002c8970 

我继续并生成核心文件。在核心转储中,我看到

(gdb) p &buffer[0]
$2 = (char (*)[80]) 0x1002c9a80 

两个位置之间的差异是 1110。

我的问题是为什么我会在核心文件中看到这种差异?任何线索将不胜感激!

谢谢 John

编辑澄清一下,问题不在于通过 GDB 生成核心 没有信号处理程序的完整代码来隔离问题。

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX 100
char buffer[100][80];

int main()
{
int i = 0;
int idx = 0;
FILE *fp = NULL;
fp = fopen("test.txt","w");
if (!fp)
    exit(1);

for (i=0; i < 5500; i++) {
    snprintf(buffer[idx],80,"%s:%d idx = %d\n",__FUNCTION__, __LINE__, i);
    idx = ((idx + 1)% MAX);
}
for (i = 0 ; i < MAX; i++)
    fprintf(fp,"%s",buffer[i]);

fclose(fp);
abort();
return 0;

问题不是

当我尝试在 GDB 中运行时,问题是在生成的核心文件中,

gdb) p buffer[0]

$2 "c0 - idx = 54\n", '\0' , "main: 20 0x7ef9524"

缓冲区偏移了 1110 字节。我使用 GDB 来检查缓冲区是否损坏。很抱歉造成混乱。

I am noticing a strange problem when I attempt to use the signal handler to dump global data to a text file and generate the core file. I would expect the data dumped to the file to be the same as that is present in the core file (it is the same global data)

in a header file foo.h

extern char buffer[100][80] ; // Hundred records each of length 80 characters

in foo.c

char buffer[100][80];

.. in a loop ..
snprintf(buffer[i],80,"%s:%d recorded idx = %d\n",__FUNCTION__,__LINE__,i);

in signal_handler.c

.. in a loop ..
fprintf(..dump data to text file..)

The data is dumped to the text file alright. I run the program in gdb and I issue the ABRT signal (the signal I am handling) via kill. In gdb I see

gdb) p &buffer[0]
$3 = (char (*)[80]) 0x1002c8970 

I continue and generate the core file. In the core dump I see

(gdb) p &buffer[0]
$2 = (char (*)[80]) 0x1002c9a80 

the difference between the two positions is 1110.

My question is why do I see this discrepancy in the core file ? Any leads would be appreciated!

Thanks
John

EDIT To clarify, the problem is not in generating the core via GDB
Full code without signal handlers to isolate the problem.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX 100
char buffer[100][80];

int main()
{
int i = 0;
int idx = 0;
FILE *fp = NULL;
fp = fopen("test.txt","w");
if (!fp)
    exit(1);

for (i=0; i < 5500; i++) {
    snprintf(buffer[idx],80,"%s:%d idx = %d\n",__FUNCTION__, __LINE__, i);
    idx = ((idx + 1)% MAX);
}
for (i = 0 ; i < MAX; i++)
    fprintf(fp,"%s",buffer[i]);

fclose(fp);
abort();
return 0;

}

The problem is not when I am trying to run in GDB, the problem is that in the core file generated,

gdb) p buffer[0]

$2 "c0 - idx = 54\n", '\0' , "main:20 0x7ef9524"

the buffer is offset by 1110 bytes. I had used GDB to check if the buffer was corrupted. Sorry about the confusion.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

雨轻弹 2024-10-25 21:45:54

请提供一个独立的示例。当核心是从 GDB 外部生成时,我可以解释不同的地址,但当它是从 GDB 内部生成时,我不能解释。

这是我所看到的:

$ cat foo.c 
#include <stdio.h>
#include <stdlib.h>

char buf[100][80];

int main()
{
  sprintf(buf[0], "hello");
  sprintf(buf[1], "hello again");

  abort();
}


$ gcc -g  foo.c -fPIC -pie   # PIE executable so its address can be randomized

$ gdb -q a.out 
Reading symbols from /tmp/a.out...done.
(gdb) r

Program received signal SIGABRT, Aborted.
0x00007ffff7a8ca75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7ffff81ff060
(gdb) sig SIGABRT

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) q

$ gdb -q a.out core
Reading symbols from /tmp/a.out...done.
[New Thread 20440]
Core was generated by `/tmp/a.out'.
Program terminated with signal 6, Aborted.
#0  0x00007ffff7a8ca75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7ffff81ff060  # same address as before
(gdb) q

$ ./a.out
Aborted (core dumped)

$ gdb -q a.out core
Reading symbols from /tmp/a.out...done.
[New Thread 20448]

Core was generated by `./a.out'.
Program terminated with signal 6, Aborted.
#0  0x00007fef9dcb5a75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7fef9e428060  # different address due to ASLR

Please provide a stand-alone example. I can explain different address when the core is produced from outside GDB, but not when it is produced from inside GDB.

Here is what I see:

$ cat foo.c 
#include <stdio.h>
#include <stdlib.h>

char buf[100][80];

int main()
{
  sprintf(buf[0], "hello");
  sprintf(buf[1], "hello again");

  abort();
}


$ gcc -g  foo.c -fPIC -pie   # PIE executable so its address can be randomized

$ gdb -q a.out 
Reading symbols from /tmp/a.out...done.
(gdb) r

Program received signal SIGABRT, Aborted.
0x00007ffff7a8ca75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7ffff81ff060
(gdb) sig SIGABRT

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) q

$ gdb -q a.out core
Reading symbols from /tmp/a.out...done.
[New Thread 20440]
Core was generated by `/tmp/a.out'.
Program terminated with signal 6, Aborted.
#0  0x00007ffff7a8ca75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7ffff81ff060  # same address as before
(gdb) q

$ ./a.out
Aborted (core dumped)

$ gdb -q a.out core
Reading symbols from /tmp/a.out...done.
[New Thread 20448]

Core was generated by `./a.out'.
Program terminated with signal 6, Aborted.
#0  0x00007fef9dcb5a75 in raise () at ../nptl/sysdeps/unix/sysv/linux/raise.c:64

(gdb) p &buf[0]
$1 = (char (*)[80]) 0x7fef9e428060  # different address due to ASLR
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文