的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

回答

相关问题