的Mac OS X 10.6：系統日誌（）EXC_BAD_ACCESS

Program received signal EXC_BAD_ACCESS, Could not access memory. 
Reason: KERN_INVALID_ADDRESS at address: 0x18d1c070 
0x96350250 in strlen() 
(gdb) bt 
#0 0x96350250 in strlen() 
#1 0x963574d1 in strdup() 
#2 0x9636e420 in asl_set_query() 
#3 0x9636e2d9 in asl_set() 
#4 0x9636d5d2 in vsyslog() 
#5 0x9636d3e1 in syslog() 
#6 0x23405e78 in gp_log (level=4, fmt=0x23429b68 "%-s:%4d: size: %d\n") at ../../rpc/mac/gp_lib.c:49 
#7 0x23404c61 in rpc_encap (out=0xbfffb23c, args=0xbfffd2d0) at ../../rpc/rpc.c:178 
#8 0x23405269 in rpc_encap_args (pkt_out=0xbfffb20c, pd=0x2342e460, args=0xbfffd2d0) at ../../rpc/rpc.c:120 
#9 0x23405549 in rpc_call_common (c=0x23053048, pd=0x2342e460, args=0xbfffd2d0, timeout=0, pkt_in=0xbfffd30c, size_in=0xbfffd308) at ../../rpc/rpc.c:227 
#10 0x234057f9 in rpc_call_actor (pd=0x2342e460, args=0xbfffd2d0, timeout=0, pkt_in=0xbfffd30c, size_in=0xbfffd308) at ../../rpc/rpc.c:204 
#11 0x23402839 in MobileIPAPIStopRoaming_w() at ../../MIPSDKv4/MobileIPSDK/MobileIP4_w.c:229 
#12 0x23401420 in MobileIPAPIStopRoaming (mipHandle=1) at ../../MIPSDKv3/MobileIPSDKv3.c:300 
#13 0x21c0e1a6 in GP_ICM_CONNMGR::CMobileIpSdk::MobileIPAPIStopRoaming() 
#14 0x21c0e6cf in GP_ICM_CONNMGR::CMobileIpSdk::Uninit() 
#15 0x1e749c19 in GP_ICM_RULEMGR::CRulesManager::Uninit() 
#16 0x0004df18 in CConnectionManager::UninitConnectionManager() 
#17 0x0013e6b4 in ICMApplication::UninitICMApplication() 
#18 0x001495b2 in main() 
(gdb) info registers 
eax   0xffffffff -1 
ecx   0x18d1c07c 416399484 
edx   0x18d1c070 416399472 
ebx   0x9636e2f0 -1774787856 
esp   0xbfffaa4c 0xbfffaa4c 
ebp   0xbfffaa78 0xbfffaa78 
esi   0x964c6cc0 -1773376320 
edi   0x18d1c07c 416399484 
eip   0x96350250 0x96350250 <strlen+16> 
eflags   0x10286 66182 
cs    0x17 23 
ss    0x1f 31 
ds    0x1f 31 
es    0x1f 31 
fs    0x0 0 
gs    0x37 55 
(gdb) frame 1 
#1 0x963574d1 in strdup() 
(gdb) frame 2 
#2 0x9636e420 in asl_set_query() 
(gdb) frame 3 
#3 0x9636e2d9 in asl_set() 
(gdb) frame 4 
#4 0x9636d5d2 in vsyslog() 
(gdb) frame 5 
#5 0x9636d3e1 in syslog() 
(gdb) frame 6 
#6 0x23405e78 in gp_log (level=4, fmt=0x23429b68 "%-s:%4d: size: %d\n") at ../../rpc/mac/gp_lib.c:49 
49  syslog(5, "%s", buf); 
(gdb) p buf 
$5 = "rpc_encap: 178: size: 48\n", '\0' <repeats 998 times> 
(gdb) p level 
$6 = 4 
(gdb) p fmt 
$7 = 0x23429b68 "%-s:%4d: size: %d\n"

的gp_log功能是這樣的：的Mac OS X 10.6：系統日誌（）EXC_BAD_ACCESS

#define LOG_DEBUG(format, ...) gp_log(DL_DEBUG, "%-s:%4d: " format, __FUNCTION__, __LINE__, ##__VA_ARGS__) 

#define LOG_MAX_LENGTH  1024 

void gp_log(int level, const char *fmt, ...) 
{ 
    va_list ap; 
    char buf[LOG_MAX_LENGTH] = {0}; 

    if (level > log_level) 
     return; 

    va_start(ap, fmt); 
    vsnprintf(buf, LOG_MAX_LENGTH, fmt, ap); 
    va_end(ap); 

    syslog(level, "%s", buf); 
    //printf("%s", buf); 
}

在rpc_encap此語句打印出的整數中的內容，從而導致此崩潰。

LOG_DEBUG("size: %d\n", size);

該崩潰是100％可重現的。我在崩潰前每次檢查syslog（）的參數： buf始終爲「rpc_encap：178：size：48 \ n」。級別始終爲4.

如果我使用printf而不是syslog，則崩潰消失。

來源

2012-02-03 Ted Feng

不好意思，但'％-s'是什麼意思？ – tia 2012-02-03 05:56:38

％-s表示在字段邊界上打印一個字符串以進行左側調整 – 2012-02-03 06:32:26

https://developer.apple.com/library/mac/#technotes/tn2004/tn2123.html：「這是由訪問未映射內存的線程引起的它可能由數據訪問或指令提取觸發;線程狀態部分描述如何區分差異。「 – unpythonic 2012-02-03 08:47:18

爲了建立爲Mac 10.5/6/7（英特爾拱），通用的庫，我上10.6 10.7編譯時添加這些標誌，

CFLAGS = -force_cpusubtype_ALL -mmacosx-version-min=10.5 -arch i386

和事故發生。

現在我刪除這些標誌，建立在10.5，沒有更多的崩潰（也是在10.5/6/7的庫工程）。

來源

2012-02-09 13:39:08

的Mac OS X 10.6：系統日誌（）EXC_BAD_ACCESS

回答

相關問題