I figured out this is because I had a vector of "Disk" objects which held pointers to "libparted resources (PedDevice*andPedDisk*) and freed them in its destructor. When the vector grew or reallocated, itcopied theDiskobjects, causing multiple objects to hold thesame pointers. When those copies were destroyed, the same libparted resources were freed multiple times," generated by ChatGPT, but I think that's correct. Making the vector hold unique_ptr<Disk> resolved the issue, which seems to support ChatGPT's explanation. On Wednesday, March 11th, 2026 at 3:47 AM, [email protected] <[email protected]> wrote:
> This happened when attempting to read the partitions of a read-only .img file > after successfully reading two others: > > Warning: Unable to open <PATH-TO-FILE>.img read-write (Read-only file > system). <PATH-TO-FILE>.img has been opened read-only. > Backtrace has 14 calls on stack: 14: > /lib/x86_64-linux-gnu/libparted.so.2(ped_assert+0x50) [0x7f8bfd564cb0] 13: > /lib/x86_64-linux-gnu/libparted.so.2(+0x12c24) [0x7f8bfd567c24] 12: > read-img(+0x8248) [0x564e3460a248] 11: read-img(+0x8215) [0x564e3460a215] 10: > read-img(+0x81f5) [0x564e3460a1f5] 9: read-img(+0x81c3) [0x564e3460a1c3] 8: > read-img(+0x7bbd) [0x564e34609bbd] 7: read-img(+0x7844) [0x564e34609844] 6: > read-img(+0x38b5) [0x564e346058b5] 5: read-img(+0x3556) [0x564e34605556] 4: > read-img(+0x3357) [0x564e34605357] 3: > /lib/x86_64-linux-gnu/libc.so.6(+0x29ca8) [0x7f8bfcf44ca8] 2: > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f8bfcf44d65] 1: > read-img(+0x3221) [0x564e34605221] A bug has been detected in GNU Parted. > Refer to the web site of parted > http://www.gnu.org/software/parted/parted.html for more information of what > could be useful for bug submitting! Please email a bug report to > [email protected] containing at least the version (3.6) and the following > message: Assertion (!disk->update_mode) at ../../libparted/disk.c:436 in > function ped_disk_destroy() failed. Aborted
