pstack看core文件所在函数名字显示????????意味着什么？

DirtyBear

core文件没有挪过地方，是在“第一现场”。
难道说是运行时的动态库搜索路径和查看这个core时的搜索路径不一样？
可是我用ldd看可执行程序，没有报告动态库"file not found"啊

请指点一二 .......

huangwei0413

编译加-g没有？

DirtyBear

没加。这是release版本的core dump
pstack看，只有栈顶的函数名是???????，别的都正常。

星空天神

pmap 看一下栈顶函数的地址指向的so，然后看看这个so有没有被替换过

rain_fish

应该是内存溢出造成的

DirtyBear

栈顶的地址在进程的堆中，不再SO空间，说明这是一个动态分配的函数指针？对于函数指针指向的函数，如果core的话，就是显示???????做为地址？

core 'core_goer_getm_0_0_1271039554_17003' of 17003:     getm -connHeartBeatTime 60 -msgTransTime 50
00466474 ???????? (780a8, ffbf839c, 0, 40c1c, 456e3, 4330c)
00028b40 __1cPGetmModelLoaderPvParserCallBack6MpnHComPipe_pcii_v_ (780a8, 1, 0, ffbf8448, 1, 40c1c) + 29c
ff20105c __1cJRCallbackMcallCallback6MpnFRBase_pvii_v_ (7906c, 78ff0, 79140, 13, 1, 137c0) + f8
ff2b2150 __1cRComPipe_ICallback6Fpcpi1_v_ (7906c, 78ff0, a, 13, 1, 0) + 20c
ff08a2f0 ipc_IeCallProc (6d680, 6d680, ffbf4558, ffbf6558, 1, ff2b1f44) + 18
ff08a9e8 ipc_mainloop (b6bae, 98e8f, 6d680, 1, ffbf85d8, ff09abc0) + 34
00024d4c main     (22db8, ffbf86c8, 1, 40c1c, 49104, 84e + 11d4
0001b200 _start   (0, 0, 0, 0, 0, 0) + 108

xiongzh-113> pmap core_zcydsf867ha_getm_0_0_1271039554_17003
core 'core_zcydsf867ha_getm_0_0_1271039554_17003' of 17003:     getm -connHeartBeatTime 60 -msgTransTime 50
00010000     128K r-x--
00030000       8K r-x--
00040000      32K rwx--
00048000      32K rwx--
00050000     192K rwx--    [ heap ]
C0000000      24K rwx--
D0000000   20480K rwx--
D1500000   20480K rwx--
FEAC0000      64K rwx--
FEAE0000      64K rwx--
FEB00000      64K rwx--
FEB20000     192K r-x--  /usr/lib/libresolv.so.2
FEB50000      48K r-x--
FEB6C000      16K rwx--  /usr/lib/libresolv.so.2
FEB80000     832K r-x--  /usr/lib/libc.so.1
FEC50000      56K r-x--
FEC6E000      40K rwx--
FEC78000       8K rwx--
FEC80000      64K r-x--  /usr/lib/cpu/sparcv8plus/libCstd_isa.so.1
FEC90000      48K r-x--
FECAA000      16K rwx--
FECB0000      32K r-x--  /usr/ucblib/libucb.so.1
FECC8000       8K rwx--
FECD0000      48K r-x--  /usr/lib/libCrun.so.1
FECEA000       8K rwx--  /usr/lib/libCrun.so.1
FECEC000      16K rwx--  /usr/lib/libCrun.so.1
FED00000    1408K r-x--  /usr/lib/libCstd.so.1
FEE60000      40K r-x--
FEE78000      40K rwx--  /usr/lib/libCstd.so.1
FEE90000      16K r-x--  /usr/lib/libm.so.1
FEEA2000       8K rwx--
FEEB0000     128K r-x--  /usr/lib/libiostream.so.1
FEED0000      56K r-x--  /usr/lib/libm.so.1
FEEEC000      16K rwx--  /usr/lib/libiostream.so.1
FEF00000     576K r-x--  /usr/lib/libnsl.so.1
FEF90000       8K r-x--
FEFA2000      40K rwx--
FEFAC000      24K rwx--
FEFD0000     128K r-x--  /usr/lib/libelf.so.1
FEFF0000       8K rwx--
FF000000      48K r-x--  /usr/lib/libsocket.so.1
FF01C000       8K rwx--
FF020000      24K r-x--  /usr/lib/libgen.so.1
FF036000       8K rwx--  /usr/lib/libgen.so.1
FF040000     128K r-x--
FF060000      32K r-x--
FF076000      16K rwx--
FF080000      48K r-x--
FF090000      24K rwx--
FF09A000      16K rwx--
FF09E000       8K rwx--
FF0A0000     768K rwx--
FF160000      16K rwx--
FF170000       8K r-x--
FF180000      16K rwx--
FF190000      16K r-x--
FF1A2000       8K rwx--
FF1B0000      64K r-x--
FF1C0000      16K r-x--
FF1D2000      64K rwx--
FF1E2000      40K rwx--
FF1F0000     192K r-x--
FF220000      24K r-x--
FF234000      16K rwx--
FF240000     128K r-x--
FF260000      24K r-x--
FF270000       8K rwx--
FF274000      32K rwx--
FF280000      32K r-x--
FF290000       8K rwx--
FF296000       8K rwx--
FF2A0000      64K r-x--
FF2B0000      24K r-x--
FF2C0000       8K rwx--
FF2C4000      16K rwx--
FF2D0000     128K r-x--
FF2FE000      24K rwx--
FF310000      64K r-x--
FF320000      32K r-x--
FF330000       8K rwx--
FF336000      16K rwx--
FF340000     128K r-x--
FF360000      16K r-x--
FF372000      24K rwx--
FF380000      48K r-x--
FF390000       8K rwx--
FF39A000      16K rwx--
FF3A0000       8K r-x--
FF3B0000     192K r-x--  /usr/lib/ld.so.1
FF3E0000      16K r-x--  /usr/lib/ld.so.1
FF3E8000       8K rwx--
FF3F0000       8K rwx--
FF3F4000       8K rwx--
FF3F6000       8K rwx--
FFBE0000     128K rw---    [ stack ]
total     48344K

DirtyBear

这个core发生在一个回调函数中。当时有可能收到TERM信号，但是程序没有处理这个信号。还有可能收到HUG信号，在HUG信号处理函数里面做了一点事情。
这种现象，是说明了收到TERM信号，进程退出，回收了堆空间，导致回调出错吗？有这可能吗？
还是在这个函数指针被释放掉了？

就是不明白为什么函数名称在core文件中显示为 ??????????

DirtyBear

应该是内存溢出造成的
rain_fish 发表于 2010-04-21 12:19

    program terminated by signal SEGV (no mapping at the fault address)

还有这个SEGV

能证明是内存溢出么？

DirtyBear

Core掉的函数地址怎么会在堆中呢 ......................

sunlan

应该是内存溢出造成的
rain_fish 发表于 2010-04-21 12:19

    同意