Error PMDK "Segmentation fault (core dumped)" when reopen the pool has already data!!!

[nghiadinhhieu]

Hi All,
For PMDK environment when I first run the pool initialization and data generation everything is ok. When you turn off the program and run again, read data from the pool that already has data, it will be dumped by the system with the error "Segmentation fault (core dumped)".
Thank you very much.

[Chris-NaN]

This bug could be fixed by adding D_RW(bt)->constructor(pop); (reconstruct btree) after reading data from pool again.

[LikoJ]

Hi All,
I have also encountered this problem. The program can run correctly the first time, but an segmentation fault will occur when executed again. This is my command.

[jbyao@node20 single_pmdk]$ sudo rm -rf /mnt/persist-memory/pmem_yjb_1/*
[jbyao@node20 single_pmdk]$ sudo ./btree -n 2000 -w 0 -p /mnt/persist-memory/pmem_yjb_1/test.pool -i ../sample_input.txt
INSERT elapsed_time: 1777, Avg: 0.888500
SEARCH elapsed_time: 176, Avg: 0.088000
[jbyao@node20 single_pmdk]$ sudo ./btree -n 2000 -w 0 -p /mnt/persist-memory/pmem_yjb_1/test.pool -i ../sample_input.txt
Segmentation fault

The segmentation fault occurs when the first key is inserted.

108	      D_RW(bt)->btree_insert(keys[i], (char *)keys[i]);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79b60d5 in pmemobj_persist () from /usr/lib64/libpmemobj.so.1

The solution @Chris-NaN proposed can indeed make the program run without this error. However, the function 'constructor' will recreate the B+tree and make existed data lost. In this way, the program will of course run correctly just like the first time.
Any other idea to solve this? Thank you very much.

By the way, some 'break;'s are missed in FAST_FAIR/single_pmdk/src/test.cpp:38-43.

[Jonyleo]

Not sure how useful this response is after 1 year but:

The issue is that the locks are being persisted, but if you open a pool from a previous execution, the locks should be reinitialized since pthread's internal data is not persisted.

One solution is to reinitialize all locks after reopening a pool.
Another approach is to decouple the locks from the persistent data (this might be more performant)

Indeed running the constructor after reopening the pool will remove this bug but you will also lose the previous data, aka the point of a persistent application.