阅读 315

读者问答:Go 编程怎么也有踩内存?|Go主题月

[toc]

原创不易,欢迎关注公众号:奇伢云存储

image.png

前情概要

有位读者群里抛出过一段自己研究的代码,并附上这么一个问题:

image.png 代码截屏:

image.png 为了刚好的研究,下面贴出来代码文本:

package main

import (
    "fmt"
    "reflect"
    "unsafe"
)

func StringToByte(key *string) []byte {
    strPtr := (*reflect.SliceHeader)(unsafe.Pointer(key))
    strPtr.Cap = strPtr.Len
    b := *(*[]byte)(unsafe.Pointer(strPtr))
    return b
}

func main() {
    decryptContent := "/AvYEjm4g6xJ3LVrk2/Adk"
    iv := decryptContent[0:16]
    key := decryptContent[2:18]
    fmt.Println(&iv)
    fmt.Println(&key)
    ivBytes := StringToByte(&iv)
    keyBytes := StringToByte(&key)
    fmt.Println(string(ivBytes))
    fmt.Println(string(keyBytes))
}
复制代码

思考第一个问题:为什么会报错?

我自己也编译跑了下,确实是得到如下错误。为什么会出现这个问题?其实文章标题都已经说明了,就是踩内存。那现在我们就是要先分析怎么踩的内存?

sh-4.4# ./test
0xc0000821e0
0xc0000821f0
/AvYEjm4g6xJ3LVr
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x45d1c6]

goroutine 1 [running]:
main.main()
	/home/qiya/test.go:25 +0x37f
复制代码

之前我在深入剖析 Go nil 的文章里有提到过,一定要理解变量结构体本身被管理的结构

字符串类型的变量,本身占用 16 字节,有一个指针指向一块内存,这个内存才是字符串存储的位置,还有一个长度字段标识字符串的长度。如下:

type  string struct {
    uint8 *str;
    int len;
}
复制代码

slice 的变量本身占用 24 字节,有 3 个 8 字节的字段。Data 指向一个 byte 内存块,Len 标识当前有效的元素位置,Cap 标识这个动态数组的物理长度。

type SliceHeader struct {
   Data uintptr
   Len  int
   Cap  int
}
复制代码

现在我们在仔细看下程序里面的 StringToByte 函数,我们看到在 main 函数里,直接取了 keyiv 这两个变量本身的地址,作为参数传进了 StringToByte ,随后在这个函数里,把这个地址通过 unsafe 库强转类型,当作 slice 管理结构来用,重点来了,且覆盖写 strPtr.Cap 这个字段这就踩内存了,往后多踩了 8 字节的内存

我就代码执行一步步分析下:

执行完以下代码:

    decryptContent := "/AvYEjm4g6xJ3LVrk2/Adk"
    iv := decryptContent[0:16]
    key := decryptContent[2:18]
复制代码

内存栈如下:

image.png 在看 22,23 的代码:

    ivBytes := StringToByte(&iv)
    keyBytes := StringToByte(&key)
复制代码

然后,经过 22 行代码执行第一个 StringToByte 函数之后(也就是第一次踩内存),由于传进去的是变量 iv 的地址,于是在函数 StringToByte 里往后多踩了 8 字节,也就是说把变量 key 的头 8 字节踩掉了。效果如下:

image.png

key 的头 8 个字节原本是个地址,指向堆上内存字符串所在位置。现在却被无情的踩成了一个整数 16 。

然后, StringToByte 函数把这 24 个字节复制给一个栈上的局部变量 ivBytes , ivBytes 的变量值如下:

*str => 0x4c253b
len => 16
cap => 16  
复制代码

接着,运行了第 23 行,又执行了一次 StringToByte 的函数,这次传入的地址是 key 变量的地址,又是往后踩了 8 字节。这次踩到谁了?看一眼 key 变量里现在的内容,哈哈哈,如下:

(gdb) x/14gx 0xc0000821f0
0xc0000821f0:	0x0000000000000010	0x0000000000000010
0xc000082200:	0x0000000000000010	0x0000000000000000
复制代码

0xc000082200 这个地址也是个无妄之灾,[汗]。可以看到 key 变量本身变成双 16 了。我们在看一样栈上变量的样子:

image.png 然后, StringToByte 函数把这 24 个字节复制给一个栈上的局部变量 keyBytes , keyBytes 的变量值如下:

image.png

继续往后看,24,25 行:

    fmt.Println(string(ivBytes))
    fmt.Println(string(keyBytes))
复制代码

这两行代码的作用是:

  1. 先把 ivByteskeyBytes 这两个 slice 转成 string 类型,然后打印出来,
  2. string(ivBytes) 调用的函数是 runtime.slicebytetostring

汇编能够看到 string(ivBytes) 实际的调用函数,如下:

   0x0000000000491d2f <+671>:   callq  0x447f70 <runtime.slicebytetostring>
复制代码

再看一样 slicebytetostring 原型如下:

func slicebytetostring(buf *tmpBuf, b []byte) (str string) {

}
复制代码

先说一下第一个参数,这是一个指针,这个指针就是 sliceheader 的第一个字段,也就是 Data 指针字段。

继续看 24 行代码的运行,这行代码为什么不会报错,因为 ivBytes 变量没事。ivBytes 能够转成 string ,其中 ivBytes 的变量如下:

*str => 0x4c253b
len => 16
cap => 16  
复制代码

但是 25 行代码则会出 panic(还记得吗?我们文章最开始的截图,panic 的位置就是 25 行),但是变量 key 被踩了呀,导致 keyBytes 这个变量也是错的。

*str => 16
len => 16
cap => 16 
复制代码

本应该是指针的字段,却活生生被踩成了 16 ,然后把这个值 16 当作指针传递到 slicebytetostring 函数里去转类型,如果这都不出非法地址的 panic ,那才真的是神奇了。

image.png 这个就是为什么出 panic 的原因了。

思考第二个问题:为什么 22,23 调换下顺序就可以了?

怎么踩的内存,已经清楚了,但这位读者朋友,又深入问了一句:

image.png 是啊,为什么了?其实你只需要像上面一样,画一张图就就很简单了。22,23 调换一下顺序的区别就只在于换成先踩了谁的内存而已。

    keyBytes := StringToByte(&key)
    ivBytes := StringToByte(&iv)
复制代码

由于 keyBytes := StringToByte(&key) 执行的时候踩的是后面的地址,但是 iv 地址是在 key 前面的,所以没有被踩到,是完好的内存,把 key 后面不知名的 8 字节踩了。最后 keyBytes 值如下:

*str => 0x4c253d
len => 16
cap => 16
复制代码

所以在执行的 ivBytes := StringToByte(&iv) 的时候 ivBytes 的值正常:

*str => 0x4c253b
len => 16
cap => 16
复制代码

当然了,最后还是顺手把变量 key 的头部踩成 16 了,不过此时已经没有影响,因为下面用的是 keyBytes, ivBytes ,所以程序自然可以正常运行。

思考第三个问题:怎么才能把程序改正确?

package main

import (
    "fmt"
    "reflect"
    "unsafe"
)

func StringToByte(key *string) []byte {
    slic := reflect.SliceHeader{}
    slic = *(*reflect.SliceHeader)(unsafe.Pointer(key))
    slic.Cap = slic.Len
    b := *(*[]byte)(unsafe.Pointer(&slic))
    return b
}

func main() {
    decryptContent := "/AvYEjm4g6xJ3LVrk2/Adk"
    iv := decryptContent[0:16]
    key := decryptContent[2:18]

    fmt.Println(iv)
    fmt.Println(key)

    ivBytes := StringToByte(&iv)
    keyBytes := StringToByte(&key)

    fmt.Println(string(ivBytes))
    fmt.Println(string(keyBytes))
}
复制代码

上面的程序我只改动了 StringToByte 函数,只改了 2 行代码。

    slic := reflect.SliceHeader{}
    slic = *(*reflect.SliceHeader)(unsafe.Pointer(key))
复制代码

加了这两行代码之后,就不会踩到外面的内存了,从而杜绝踩内存导致的奇怪问题。具体原理小伙伴如果还有不清楚的,可以自己 gdb 分析下,或者找我交流。

当然了,这个读者朋友也是在研究和学习当中,现实项目中应该不至于出现这种奇怪的代码。但是这个小问题引发的思考却值得记录和学习。

原创不易,欢迎关注公众号:奇伢云存储

总结

  1. Go 并非没有踩内存和其他内存问题,只要你想越过 Go 的类型校验,那么所有的内存问题可能你都要面对;
  2. unsafe 这个库已经这么明显的名字了,就是告诉你不安全,谨慎使用。所以说,除非有必须要用的理由,且明确知道自己的行为导致的后果才去使用,否则绕开走吧;
  3. string 的管理结构是 16 字节,slice 的管理结构是 24 字节,记住哦;

原创不易,欢迎关注公众号:奇伢云存储

文章分类
后端
文章标签