Joachim Breitner wrote:
> thanks for the report! Unfortunately, I can’t really tell what’s going
> wrong here. It looks like it’s actually the _writing_ of the recovered
> samples that is broken here.
Indeed, but it only happens with the corrupted file, so it must somehow
be the data that is
Memory use is still ~2.4 gb (profile below).
Mon Apr 22 17:57 2019 Time and Allocation Profiling Report (Final)
arbtt-recover +RTS -p -RTS -i capture.log -o capture.log.recovered
total time = 292.96 secs (292957 ticks @ 1000 us, 1 processor)
total
Joachim Breitner wrote:
> Can you try the current git version, and see if it works for you?
I can't get that to build with cabal or stack..
--
see shy jo
Joachim Breitner wrote:
> is that on a broken log file, or one that has errors?
The file does have a lot of problems:
Found header, continuing... (146048068 bytes to go)
Failed to read value at position 74939844:
Unsupported TimeLogEntry version tag 0
CallStack (from HasCallStack):
error,
Package: arbtt
Version: 0.10.1-1
Severity: normal
I'm running arbtt-recover on a 140 mb capture.log, it's written out 75
mb of capture.log.recovered so far, and it's using 2.5 gb of memory.
I don't think it should need to keep the whole log read so far in
memory, since it's written out to disk,
5 matches
Mail list logo
