DockerContainer下gdb无法正常工作的解决办法

昨天想在Mac上使用gdb调试一个Linux下编译的动态链接库, 以正常选项启动一个docker container, 运行gdb却发现如下错误提示.

warning: Error disabling address space randomization: Operation not permitted
Cannot create process: Operation not permitted
During startup program exited with code 127.
(gdb)

在google搜索结果里第6个才找到正确答案, https://www.google.com/search?safe=off&q=docker+gdb+warning%3A+Error+disabling+address+space+randomization%3A+Operation+not+permitted+Cannot+create+process%3A+Operation+not+permitted+During+startup+program+exited+with+code+127&oq=docker+gdb+warning%3A+Error+disabling+address+space+randomization%3A+Operation+not+permitted+Cannot+create+process%3A+Operation+not+permitted+During+startup+program+exited+with+code+127, 原来是docker run中的一个不太常用的选项, docker run –privileged, 加上即可.

于是找官方文档查看此选项的解释, 了解到: 默认docker是以受限模式下运行container, 如不能在container中运行再运行一个docker, 不能访问宿主机上的真实设备, /dev/, gdb无法访问真实的内存设备.
>

Runtime privilege and Linux capabilities

--cap-add: Add Linux capabilities
--cap-drop: Drop Linux capabilities
--privileged=false: Give extended privileges to this container
--device=[]: Allows you to run devices inside the container without the --privileged flag.

By default, Docker containers are “unprivileged” and cannot, for example, run a Docker daemon inside a Docker container. This is because by default a container is not allowed to access any devices, but a “privileged” container is given access to all devices (see the documentation on cgroups devices).

When the operator executes docker run –privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor or SELinux to allow the container nearly all the same access to the host as processes running outside containers on the host. Additional information about running with –privileged is available on the Docker Blog.

If you want to limit access to a specific device or devices you can use the –device flag. It allows you to specify one or more devices that will be accessible within the container.

>$ docker run --device=/dev/snd:/dev/snd ...
>
分享到 评论

Go sync.Pool Slice Benchmark

纠结于[]struct还是[]*struct
直接make([]struct,0) 后append 还是 用sync.Pool make([]struct,100)

写段代码跑个分, 结论是

  1. []*struct的要比[]struct多n次取指针的内存分配, 所有更慢, 如果不用修改结构体元素内的值, 没有必要用指针切片
  2. append[]*struct要比[]struct
  3. sync.Pool效果明显

benchmark结果

BenchmarkStructSliceWithoutPool-8 200000 5458 ns/op 16320 B/op 8 allocs/op
BenchmarkStructPointerSliceWithoutPool-8 200000 6045 ns/op 8504 B/op 109 allocs/op
BenchmarkStructSliceWithPool-8 1000000 1287 ns/op 32 B/op 1 allocs/op
BenchmarkStructPointerSliceWithPool-8 300000 4910 ns/op 6498 B/op 102 allocs/op

benchmark代码

package main
import (
"sync"
"testing"
)
var structSlicePool = sync.Pool{
New: func() interface{} {
return make([]Basic, 100)
},
}
var structPointerSlicePool = sync.Pool{
New: func() interface{} {
return make([]*Basic, 100)
},
}
type Basic struct {
Id, N1, N2, N3, N4, N5 int
Name string
}
func BenchmarkStructSliceWithoutPool(b *testing.B) {
for i := 0; i < b.N; i++ {
var list []Basic
for j := 0; j < 101; j++ {
var data = Basic{Id: j, Name: "Name"}
list = append(list, data)
}
}
}
func BenchmarkStructPointerSliceWithoutPool(b *testing.B) {
for i := 0; i < b.N; i++ {
var list []*Basic
for j := 0; j < 101; j++ {
var data = Basic{Id: j, Name: "Name"}
list = append(list, &data)
}
}
}
func BenchmarkStructSliceWithPool(b *testing.B) {
for i := 0; i < b.N; i++ {
list := structSlicePool.Get().([]Basic)
initLen := len(list)
for j := 0; j < 101; j++ {
var data = Basic{Id: j, Name: "Name"}
if j < initLen {
list[j] = data
} else {
list = append(list, data)
}
}
structSlicePool.Put(list)
}
}
func BenchmarkStructPointerSliceWithPool(b *testing.B) {
for i := 0; i < b.N; i++ {
list := structPointerSlicePool.Get().([]*Basic)
initLen := len(list)
for j := 0; j < 101; j++ {
var data = Basic{Id: j, Name: "Name"}
if j < initLen {
list[j] = &data
} else {
list = append(list, &data)
}
}
structPointerSlicePool.Put(list)
}
}
分享到 评论