linux gdb升级,linux 下 gdb 调试。

目前在ST的sdk上跑了个程序，大概就是开两个线程，线程A 执行ST平台的I2C读写操作，线程2执行调用system()函数 umount/mount U盘。

发现奇怪的现象：

如果线程A的优先级 大于 线程B的优先级，程序在运行一段时间后会发生“segmentions fault”

如果线程A的优先级 小于 线程B的优先级，则能正常工作。(拷机测试了24小时正常)

为了知道根本原因，我决定用gdb 工具来跟踪。

根据网上的资料，进入终端后

执行：

ulimit -c 1024

在执行所要测试的程序，当发生异常退出后，会生成core文件。

我们先自己写个有问题的C语言测试一下ST的gdb运行环境是否正常：

gcc -Wall -g test.c

生成了a.out 可执行文件。

启动目标板，进入终端执行：

ulimit -c 1024

a.out

果然生成了core.xxx文件 ，//xxx为程序的id 号。

接着执行：

gdb --core=core.xx

输出：

GNU gdb STMicroelectronics/Linux Base 6.8-17 [build May 26 2009]

Copyright (C) 2008 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "sh4-linux".

Failed to read a valid object file image from memory.

Core was generated by `./a.out'.

Program terminated with signal 11, Segmentation fault.

[New process 1217]

#0  0x004003f6 in ?? ()

(gdb) where

#0  0x004003f6 in ?? ()

(gdb)

#0  0x004003f6 in ?? ()

(gdb)

#0  0x004003f6 in ?? ()

接下来执行：

(gdb) file a.out

输出：

Reading symbols from /a.out...done.

接着执行：

(gdb) bt

输出：

#0  0x004003f6 in sub () at test.c:17

#1  0x004003cc in main () at test.c:8

显示在test.c 的17 行 和8 行可能出现问题。

以上操作，显示了ST提供的gdb运行环境没有问题。那接下来同样的方法跑我的应用：main_mb680_7105_ST40_LINUX_32BITS.out

可是当执行到， (gdb)bt

却输出：

#0  0x2f719f60 in ?? ()

#1  0x2f719f60 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

这是怎么回事呢？

在到网上查查，看有没有人碰到相同的问题，先记录下来。