ktx/pocket_archive

Watch

Fork 0

CLI segfault when invoking `pkar dump-ll` on multiple IDs #72

New issue

Closed

opened 2026-07-31 18:02:18 +00:00 by scossu · 4 comments

scossu commented

2026-07-31 18:02:18 +00:00

Owner

To reproduce, in git root:

export PKAR_CONFIG_DIR=test/config/
echo 'yes' | pkar init
pkar deposit test/assets/sip/pkar_submission-demo.csv
pkar dump-ll $(pkar list -t container)

The last line produces the header and first data line of the LL CSV, then exits with a segfault. Not 100% of the time.

pkar list -t container | pkar dump-ll does not seem to reproduce the problem.

Valgrind hasn't caught any problem so far.

To reproduce, in git root: ``` export PKAR_CONFIG_DIR=test/config/ echo 'yes' | pkar init pkar deposit test/assets/sip/pkar_submission-demo.csv pkar dump-ll $(pkar list -t container) ``` The last line produces the header and first data line of the LL CSV, then exits with a segfault. Not 100% of the time. `pkar list -t container | pkar dump-ll` does not seem to reproduce the problem. Valgrind hasn't caught any problem so far.

scossu added this to the v1.0.0 milestone

2026-07-31 18:02:18 +00:00

scossu added the

labels

2026-07-31 18:02:18 +00:00

scossu commented

2026-07-31 18:08:59 +00:00

Author

Owner

At random times, I get the message:

14:06:36 WARN  src/term.c:813: Characters <>" {}|\^` are not valid in a URI. Got: @|`G�U

which is in the Volksdata term_init function. Possibly some term is being initialized with garbage data.

At random times, I get the message: ``` 14:06:36 WARN src/term.c:813: Characters <>" {}|\^` are not valid in a URI. Got: @|`G�U ``` which is in the Volksdata `term_init` function. Possibly some term is being initialized with garbage data.

scossu commented

2026-07-31 18:16:25 +00:00

Author

Owner

Interestingly, this only happens when PKAR_LOGLEVEL env var is set to warn or err. With more verbose logging, the output is correct.

Thinking that this would be a red herring, because the more verbose output may be overwriting recently freed memory with apparently valid data, I compared the outputs of multiple runs of the command, and they all turned out identical. If there was memory corruption, the outputs could be different, or they would have awkward data, or they would cause errors elsewhere along the way. I don't really know what to do with this information.

Interestingly, this only happens when `PKAR_LOGLEVEL` env var is set to `warn` or `err`. With more verbose logging, the output is correct. Thinking that this would be a red herring, because the more verbose output may be overwriting recently freed memory with apparently valid data, I compared the outputs of multiple runs of the command, and they all turned out identical. If there was memory corruption, the outputs could be different, or they would have awkward data, or they would cause errors elsewhere along the way. I don't really know what to do with this information.

scossu commented

2026-07-31 18:35:05 +00:00

Author

Owner

Same segfault with

pkar dump-ll muhZIUbBLh4TBXWd jLYMjUtQpO9NuLPL wqUANcxdRIC3KQuU neCotOV03zeeoDwy 7K45tyYHxDIptKR2 DFf0nX3xENdEb6GA

Same segfault with ``` pkar dump-ll muhZIUbBLh4TBXWd jLYMjUtQpO9NuLPL wqUANcxdRIC3KQuU neCotOV03zeeoDwy 7K45tyYHxDIptKR2 DFf0nX3xENdEb6GA ```

scossu changed title from ~~Segfault in CLI when chaining pkar list with pkar dump-ll~~ to CLI segfault when invoking pkar dump-ll on multiple IDs

2026-08-03 15:18:34 +00:00

scossu commented

2026-08-09 04:27:29 +00:00

Author

Owner

Fixed in ktx/volksdata_lua@e8f4449a8b .

Fixed in https://git.knowledgetx.com/ktx/volksdata_lua/commit/e8f4449a8b1d334a75fbb4b98ecbc59b31125033 .

scossu closed this issue

2026-08-09 04:27:30 +00:00

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

ktx/pocket_archive#72

No description provided.

Rows
Columns

CLI segfault when invoking pkar dump-ll on multiple IDs #72

CLI segfault when invoking `pkar dump-ll` on multiple IDs #72