#pragma pack(1) 单身狗,自己挖坑自己踩

本文记录了一次在使用DPDK开发过程中遇到的奇怪bug,即通过rte_eal_remote_launch调用的函数中,传入结构体的成员指针值发生变化导致程序崩溃。通过对内存对齐问题的深入分析及解决过程,最终确定问题原因并给出了解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

周六天不好,还被叫去加班写文档,心情很不愉快;周日阳光明媚,高高兴兴晃荡晃荡去加班调BUG

问题:main函数调用dpdk静态库函数rte_eal_remote_launch,传入回调函数指针capture_core,以及capture_core要用到的结构体指针config,但是capture_core被调用后发现main设置的config里的一个指针成员mutex值不对了,结果__sync_bool_compare_and_swap (config->mutex, lock, 1)报segmentfault

结构体:

struct core_capture_config {
        struct rte_ring * ring[RING_MAX];
        bool volatile * stop_condition;
        struct core_capture_stats * stats;
        uint8_t port;
        uint8_t queue;
        unsigned int ring_num;
        hashtable_t *ht;
        int *mutex;
        int i;
        unsigned long bond_ip;
};

思路:

1.多线程什么地方把内存给破坏了?

停了所有其他线程,可是还是一样的问题

2.用到valgrind看看什么地方内存使用有问题?

然而用了dpdk,valgrind跑不起来,ERROR: This system does not support "RDRAND" valgrind dpdk,网上说是valgrind的缺陷,可是提供的解决方案补丁也没好用

而且进一步发现在main函数里看config成员值并没有变

3.想不通,难道rte_eal_remote_launch使用的config并不是我传的config,而是复制了一份?

gdb看了一下两个config地址发现是一样的。。。

虽然基本排除dpdk库的问题,而且心想有问题得排查自己的代码,像DPDK这种INTEL提供的库你还想轻易找个BUG,但毕竟人家是开源的

lib/librte_eal/linuxapp/eal/eal_thread.c:

主要函数:

/*
 * Send a message to a slave lcore identified by slave_id to call a
 * function f with argument arg. Once the execution is done, the
 * remote lcore switch in FINISHED state.
 */
int
rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
{
	int n;
	char c = 0;
	int m2s = lcore_config[slave_id].pipe_master2slave[1];
	int s2m = lcore_config[slave_id].pipe_slave2master[0];

	if (lcore_config[slave_id].state != WAIT)
		return -EBUSY;

	lcore_config[slave_id].f = f;
	lcore_config[slave_id].arg = arg;

	/* send message */
	n = 0;
	while (n == 0 || (n < 0 && errno == EINTR))
		n = write(m2s, &c, 1);
	if (n < 0)
		rte_panic("cannot write on configuration pipe\n");

	/* wait ack */
	do {
		n = read(s2m, &c, 1);
	} while (n < 0 && errno == EINTR);

	if (n <= 0)
		rte_panic("cannot read on configuration pipe\n");

	return 0;
}

/* main loop of threads */
__attribute__((noreturn)) void *
eal_thread_loop(__attribute__((unused)) void *arg)
{
	char c;
	int n, ret;
	unsigned lcore_id;
	pthread_t thread_id;
	int m2s, s2m;
	char cpuset[RTE_CPU_AFFINITY_STR_LEN];

	thread_id = pthread_self();

	/* retrieve our lcore_id from the configuration structure */
	RTE_LCORE_FOREACH_SLAVE(lcore_id) {
		if (thread_id == lcore_config[lcore_id].thread_id)
			break;
	}
	if (lcore_id == RTE_MAX_LCORE)
		rte_panic("cannot retrieve lcore id\n");

	m2s = lcore_config[lcore_id].pipe_master2slave[0];
	s2m = lcore_config[lcore_id].pipe_slave2master[1];

	/* set the lcore ID in per-lcore memory area */
	RTE_PER_LCORE(_lcore_id) = lcore_id;

	/* set CPU affinity */
	if (eal_thread_set_affinity() < 0)
		rte_panic("cannot set affinity\n");

	ret = eal_thread_dump_affinity(cpuset, RTE_CPU_AFFINITY_STR_LEN);

	RTE_LOG(DEBUG, EAL, "lcore %u is ready (tid=%x;cpuset=[%s%s])\n",
		lcore_id, (int)thread_id, cpuset, ret == 0 ? "" : "...");

	/* read on our pipe to get commands */
	while (1) {
		void *fct_arg;

		/* wait command */
		do {
			n = read(m2s, &c, 1);
		} while (n < 0 && errno == EINTR);

		if (n <= 0)
			rte_panic("cannot read on configuration pipe\n");

		lcore_config[lcore_id].state = RUNNING;

		/* send ack */
		n = 0;
		while (n == 0 || (n < 0 && errno == EINTR))
			n = write(s2m, &c, 1);
		if (n < 0)
			rte_panic("cannot write on configuration pipe\n");

		if (lcore_config[lcore_id].f == NULL)
			rte_panic("NULL function pointer\n");

		/* call the function and store the return value */
		fct_arg = lcore_config[lcore_id].arg;
		ret = lcore_config[lcore_id].f(fct_arg);
		lcore_config[lcore_id].ret = ret;
		rte_wmb();
		lcore_config[lcore_id].state = FINISHED;
	}

	/* never reached */
	/* pthread_exit(NULL); */
	/* return NULL; */
}
可以看出他对参数arg是没有额外处理的,而且在这里加了输出语句发现一进rte_eal_remote_launch,config->mutex指针的值就变了,真是神奇。。。

3.静态库和main函数malloc出来的地址空间不一致?

这个之前在win上使用dll遇到过,但是linux也没查到相关内容,而且这块代码之前都是好使的,调用方法也是标准的

4.进一步gdb调试发现结构体成员值有点串,相邻成员之间的值好像拼在一起了

发现相邻成员混在一起猜测是对齐的问题,gdb打印各变量地址:

函数调用外


函数调用内

而且sizeof结构体也不一样,应该就是对齐的问题的,但是想不通,同一个程序同一个结构体在不同地方怎么会对齐方式不同呢
既然发现可能是对齐问题那就用pack指定一下对齐方式吧,可惜基础不扎实,写了个pack(32)...没好使
就这样BUG没解决,周一上班可咋整。。。
没办法就各种问人,虽然都没有明确答案,不过感谢老段特地打电话过来,更坚定了是对齐的问题,而刘兄的话更是一语惊醒梦中人,加个pack(1)试试啊。。我已经觉得我的pack(32)是个什么鬼了。。。

今天一早跑去接着调,一编译才发现pack(32)直接编译warning了。。。赶紧换成pack(1),果然没问题了。。。

这样就算基本解决问题了,可是还是想不通为啥要指定pack,(。。。中间有点思路记不清了),全局搜索了一下pack,基本都是一些头文件里涉及网络传输的结构体被pack(1),pack()包裹的,然而有部分我新增的功能是从原有代码复制改写的,有一处只有pack,前面没有对应的pack(1),这倒问题不大,另一处是只有pack(1)而没有pack(),结果一个c文件包含了这个头文件和core_capture_config所在头文件,而另一个c文件只包含了core_capture_config所在头文件,这样两边对齐方式就不一样了,把新增的代码改正了,core_capture_config也就不需要指定pack了

为啥优快云代码格式只有C++没有C

### 关于 `#pragma pack` 和 `#pragma anon_unions` 的用法详解 #### 1. `#pragma pack` 的作用 `#pragma pack` 是一种编译器指令,用于控制结构体成员之间的内存对齐方式。默认情况下,C/C++ 编译器会对结构体中的成员变量进行字节对齐优化,以提高访问速度。然而,在某些场景下(如嵌入式开发或网络通信),需要精确控制结构体的布局,此时可以使用 `#pragma pack`。 - **语法**: ```c #pragma pack(n) ``` 其中 `n` 表示指定的对齐单位,通常为 1、2、4 或 8 字节。设置后,结构体会按照该对齐方式进行排列。 - **具体功能**: - 当前文件范围内的所有后续定义都会受到此 pragma 影响。 - 如果希望仅影响特定部分代码,则可配合 `push` 和 `pop` 使用[^1]。 #### 2. `#pragma pack(push/pop)` 的作用 为了防止全局修改对齐方式的影响,可以通过 `push` 和 `pop` 来保存和恢复之前的对齐状态: - **语法**: ```c #pragma pack(push, n) // 将当前对齐方式压栈并设置新的对齐方式 ... #pragma pack(pop) // 恢复之前保存的对齐方式 ``` - **实际应用案例**: 下面是一个典型的例子,展示如何通过 `pack(push/pop)` 控制结构体内存布局: ```c #pragma pack(push, 1) // 设置对齐方式为 1 字节并对旧状态进行保存 typedef struct { char a; int b; short c; } PackedStruct; #pragma pack(pop) // 恢复原来的对齐方式 ``` 在这个例子中,`PackedStruct` 中的字段不会因为默认对齐而增加额外填充字节,从而节省空间。 #### 3. `#pragma anon_unions` 的作用 `#pragma anon_unions` 用于启用或禁用 C 结构体中的匿名联合体支持。匿名联合体允许直接访问联合体内部的成员,而不必显式指明联合体名称。 - **默认行为**: 默认情况下,许多编译器会关闭匿名联合体的支持,除非明确开启它。 - **语法**: ```c #pragma anon_unions // 启用匿名联合体支持 #pragma no_anon_unions // 禁用匿名联合体支持 (通常是默认值)[^2] ``` - **实际应用场景**: 假设有一个包含匿名联合体的结构体: ```c #pragma anon_unions // 开启匿名联合体支持 typedef struct { union { float fValue; int iValue; }; } AnonymousUnionExample; AnonymousUnionExample example; example.fValue = 3.14f; // 可以直接访问联合体成员 printf("%d\n", example.iValue); ``` 这种写法简化了代码逻辑,尤其适用于硬件寄存器映射等场合[^2]。 --- ### 总结 - `#pragma pack` 主要用来调整结构体成员间的内存对齐策略,减少不必要的填充字节。 - `#pragma pack(push/pop)` 提供了一种局部化的方式管理对齐选项,避免污染整个程序环境。 - `#pragma anon_unions` 则提供了更灵活的方式来处理匿名联合体,使得复杂的数据结构更加简洁易读。 以上工具在嵌入式系统编程以及跨平台兼容性设计中有广泛应用价值。 ```python def align_memory(size, alignment=4): """计算按指定边界对齐后的大小""" return ((size + alignment - 1) // alignment) * alignment ```
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值