[minicoredumper] [External] Debugging corrupt tar files (invalid sparse archive member)

[John Ogness]

Hi Jos,

On 2023-02-07, "Jos Hulzink (Ellips B.V.)" <jos.hulzink at ellips.com> wrote:
>> The tar files should never be invalid.
>
> Too bad this doesn't match my experience 😉 I checked whether I had
> the latest version of GNU tar, tried to play with the sparse version
> numbers and other options a bit, but no success... Since
> minicoredumper also compresses the file for us and we are able to
> decompress the file, we don't see any other way our tar archive could
> get corrupted.

minicoredumper implements its own tar routine. The problem may be there,
but usually it is because some other internal structures of the
minicoredumper are containing incorrect information.

> Sending you a core dump should not be a problem. I'll send that to you
> personally

Thanks, I'll take a look at it.

>> sysctl -w kernel.core_pipe_limit=0x7fffffff
>
> I will add that option to our settings. It will take a while before
> you get feedback on this one. (Since we don't know how to reproduce
> it, it only happens at customer sites, which are all around the world,
> and it takes a while to release and get new software versions there)

I don't expect this to make a difference because the minicoredumper was
able to complete its work.

> In your other mail you ask for errors in the log file. I attached it
> below this email. I don't see any weird errors,

Indeed, everything looks fine. The minicoredumper did not have any
problems parsing and reading the necessary memory.

> only the very last line "libminicoredumper: no dump data version
> found" triggers me.

Using libminicoredumper it is possible for applications to dynamically
mark extra data to be dumped. This message just means that the crashing
application is not using libminicoredumper or nothing special has been
marked for dumping. Since you are probably not using libminicoredumper,
this message is fine.

John Ogness