调试标准C库例程 [英] Debugging standard C library routines
问题描述
我在PPC主板上使用MontaVista Linux。
我正在使用的编译器是一个gnu交叉编译器交叉编译器
（ppc-82xx-gcc）
正在运行的应用程序/软件正在弄乱内存
，因此后续的malloc失败。
当转储应用程序核心时，我没有在
代码中获得任何回溯（尽管应用程序是使用调试符号编译的，使用-g
选项）。我得到的唯一的东西是发生崩溃的函数的地址（而不是名字）。
在我找到的代码中使用print该应用程序在调用
malloc时崩溃。我将标准C库链接为.so，这可能是
为什么没有回溯包含我的应用程序的功能。
还不够板上的内存来运行gdb。另外由于场景的复杂性，并不总是可以运行gdbserver。
有可能的方法：
1。链接一个可调试版本的stdlib，当它被转储时会在核心中放入更多的信息。
2.我可以在stdlib中启用一些断言或额外信息吗？
告诉我memry是否搞砸了。
3.有没有办法将地址映射到.so的功能
加载到内存中。或者即使我知道地址属于ta
perticaular .so
提前致谢。
ac ********* @ gmail.com 写道：
我正在PPC板上使用MontaVista Linux。
我正在使用的编译器是一个gnu交叉编译器交叉编译器
（ppc-82xx-gcc）
正在运行的应用程序/软件正在弄乱内存
由于后续malloc失败。
当转储应用程序核心时，我没有在
代码中获得任何回溯（尽管应用程序已编译带有调试符号，带-g
选项）。我得到的唯一的东西是发生崩溃的函数的地址（而不是名字）。
在我找到的代码中使用print该应用程序在调用
malloc时崩溃。我将标准C库链接为.so，这可能是
为什么没有回溯包含我的应用程序的功能。
还不够板上的内存来运行gdb。同样由于场景的复杂性，并不总是可以运行gdbserver。
有可能的方法：
1.链接stdlib的可调试版本，当它被转储时，它会在核心中放入更多信息
。
2.我可以启用一些断言或额外信息在stdlib，这将告诉我memry是否搞砸了。
3.有没有办法将地址映射到.so的功能？ />
加载到内存中。或者即使我知道地址属于ta
perticaular .so
提前致谢。
你有一个难题。
到（1）和（2）
首先，你不需要c库的完整调试版本，但仅仅是malloc / free的
。我想你不要怀疑asin（）是你问题的来源。一个这样的调试库是
http://www.hexco.de/rmdebug /
到（3）
如果我做了一个
objdump -T / lib /libc-2.2.4.so
我获得了一个带有地址的入口点列表。如果你知道
加载.so的地址你已经完成了设置。
ac ********* @ gmail.com 说：
正在运行的应用程序/软件正在弄乱内存
，因为后续的malloc失败了。
初始化每个指针。检查每个malloc / calloc / realloc以确保它在您依赖其返回值之前成功获得
。检查每个数组
访问是否在边界内（0到n - 1，对于n个元素的数组）。设置
不确定（''悬挂''）指针指向NULL。
按照这些简单的步骤将摆脱所有已知的99.90072％
与记忆相关的崩溃。
-
Richard Heathfield
Usenet是一个奇怪的地方 - dmr 29/7/1999
http://www.cpax.org.uk
电子邮件：rjh在上面的域名（但显然放弃了www）
Richard Heathfield发布：
< blockquote class =post_quotes> ac*********@gmail.com 说：
>正在运行的应用程序/软件正在弄乱内存
，因为后续的malloc失败。
初始化每个指针。
我不会建议初始化_every_指针。
#define POVER（arr） （（arr）+ sizeof（arr）/ sizeof *（arr））
int * p;
for（p = array1; POVER（array1）！= p; ++ p）/ * Something * /;
for（p = array2; POVER（array2）！= p; ++ p）/ *东西* /;
检查每个malloc / calloc / realloc以确保它在你的返回值上依赖
之前成功。
如果malloc''不到一千字节，我就不会打扰了。
检查每个数组访问是否在边界内（0到n - 1，对于数组
的n个元素）。
当回顾一个'
代码时，应该_always_注意这些事情。
设置指向NULL的不确定（''悬空''）指针。
在调试模式下，也许吧。它在发布模式下浪费了宝贵的纳秒（如果不是微秒）
。也许以下类似的事情是妥协：
#ifdef NDEBUG
#define DMODE（声明）
#else
#define DMODE（声明）声明
#endif
int main（）
{< br $>
int * p;
...
free（p）; DMODE（p = 0）;
}
-
Frederick Gotham
I am working on MontaVista Linux on a PPC board.
The compiler I am using is a gnu cross compiler cross compiler
(ppc-82xx-gcc)
The application/software that is being run, is messing up the memory
due to which a subsequent malloc fails.
When the application core is dumped I do not get any backtrace in the
code (although the application is compiled with debug symbols, with -g
option). The only thing I get is the address of the function (and not
the name) where the crash is happening.
Using prints in the code I found that application crashes while calling
malloc. I am linking the standard C library as .so, and thats probably
why there is not backtrace conatining the functions of my application.
There is not enough memory on the board to run gdb. Also due to the
complexity of the scenarios it is not always possible to run gdbserver.
It there a possible way to:
1. Link a debuggable version of stdlib which would put more information
in the core, when it is dumped.
2. Can I enable some asserts or extra information in stdlib which would
tell me if memry is being messed up.
3. Is there a way by which I can map an address to a function of .so
loaded in the memory. Or even if i know that the address belongs t a
perticaular .so
Thanks in advance.
ac*********@gmail.com wrote:I am working on MontaVista Linux on a PPC board.
The compiler I am using is a gnu cross compiler cross compiler
(ppc-82xx-gcc)
The application/software that is being run, is messing up the memory
due to which a subsequent malloc fails.
When the application core is dumped I do not get any backtrace in the
code (although the application is compiled with debug symbols, with -g
option). The only thing I get is the address of the function (and not
the name) where the crash is happening.
Using prints in the code I found that application crashes while calling
malloc. I am linking the standard C library as .so, and thats probably
why there is not backtrace conatining the functions of my application.
There is not enough memory on the board to run gdb. Also due to the
complexity of the scenarios it is not always possible to run gdbserver.
It there a possible way to:
1. Link a debuggable version of stdlib which would put more information
in the core, when it is dumped.
2. Can I enable some asserts or extra information in stdlib which would
tell me if memry is being messed up.
3. Is there a way by which I can map an address to a function of .so
loaded in the memory. Or even if i know that the address belongs t a
perticaular .so
Thanks in advance.
You have a hard problem there.
To (1) and (2)
First thing, you do not need a full debug version of the c library but
just of malloc/free. I suppose you do not suspect asin() as beeing the
source of your problems. One such a debug library is
http://www.hexco.de/rmdebug/
To (3)
If I do an
objdump -T /lib/libc-2.2.4.so
I obtain a list of entry points with their addresses. If you get to know
at which address the .so is loaded you are all set.
ac*********@gmail.com said:
The application/software that is being run, is messing up the memory
due to which a subsequent malloc fails.Initialise every pointer. Check every malloc/calloc/realloc to ensure it
succeeded before you rely on its return value. Check that every array
access is within bounds (0 to n - 1, for an array of n elements). Set
indeterminate (''dangling'') pointers to NULL.
Following these simple steps will get rid of 99.90072% of all known
memory-related crashes.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield posted:
ac*********@gmail.com said:
>The application/software that is being run, is messing up the memory
due to which a subsequent malloc fails.
Initialise every pointer.
I wouldn''t go so far as to advise to initialise _every_ pointer.
#define POVER(arr) ((arr) + sizeof(arr)/sizeof*(arr))
int *p;
for(p=array1;POVER(array1)!=p;++p) /* Something */ ;
for(p=array2;POVER(array2)!=p;++p) /* Something */ ;
Check every malloc/calloc/realloc to ensure it succeeded before you rely
on its return value.
If malloc''ing less than a kilobyte, I wouldn''t bother.
Check that every array access is within bounds (0 to n - 1, for an array
of n elements).
One should _always_ watch out for such things when looking back over one''s
code.
Set indeterminate (''dangling'') pointers to NULL.
In Debug Mode, maybe. It wastes valuable nanoseconds (if not microseconds)
in Release Mode. Maybe something like the following would be a compromise:
#ifdef NDEBUG
#define DMODE(statement)
#else
#define DMODE(statement) statement
#endif
int main()
{
int *p;
...
free(p); DMODE(p=0);
}
--
Frederick Gotham
这篇关于调试标准C库例程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
