Welcome to Snooda's Blog
由一个小概率出core看函数声明的重要性
[| 2012/01/14 23:39]
最近程序遇到一个小概率出core的bug,高压力下大概10分钟左右就会出core,gdb查看发现一个指针高四字节被置0xffffffff了,低四字节正常。
该指针是局部变量,存放在栈上,排除了线程间同步互斥写坏数据的可能。
该指针前后变量均正常,都是指针,排除了写越界的可能。
通过日志查看,在返回该指针的函数返回前,指针正常,返回后高四字节即被置0xffffffff了。推断应该是函数返回的过程中遭到了破坏。
但不知道为什么返回的过程中会出错,请教了下组内高工,高人就是高人,一听问题描述就表示应该是函数声明的问题。
原来,在调用另一个so文件中的函数时,如果没有该函数的声明,由于从该so的符号表里可以找到函数,所以编译可以通过,但gcc会把这个函数返回值按默认的int处理,这种情况下,32位机编译的程序是没问题的,但64位机上指针是8字节,导致高四字节数据丢失。但返回的指针超过int值域时,高四字节数据丢失,导致指针被破坏。
所以函数声明还是不可或缺的。
该指针是局部变量,存放在栈上,排除了线程间同步互斥写坏数据的可能。
该指针前后变量均正常,都是指针,排除了写越界的可能。
通过日志查看,在返回该指针的函数返回前,指针正常,返回后高四字节即被置0xffffffff了。推断应该是函数返回的过程中遭到了破坏。
但不知道为什么返回的过程中会出错,请教了下组内高工,高人就是高人,一听问题描述就表示应该是函数声明的问题。
原来,在调用另一个so文件中的函数时,如果没有该函数的声明,由于从该so的符号表里可以找到函数,所以编译可以通过,但gcc会把这个函数返回值按默认的int处理,这种情况下,32位机编译的程序是没问题的,但64位机上指针是8字节,导致高四字节数据丢失。但返回的指针超过int值域时,高四字节数据丢失,导致指针被破坏。
所以函数声明还是不可或缺的。