[minicoredumper] [External] Infinite loop while executing read_remote

[Jos Hulzink (Ellips B.V.)]

> -----Original Message-----
> From: John Ogness <john.ogness at linutronix.de>
> Sent: dinsdag 3 augustus 2021 17:41
> To: Jos Hulzink (Ellips B.V.) <jos.hulzink at ellips.com>;

> 
> Can you post the contents of /etc/minicoredumper/generic.recept.json? A
> problem was recently reported [0] that has been verified. It is a
> problem when files are specified in the "maps":"dump_by_name" section.

/etc/minicoredumper/generic.recept.json:
//////

{
    "stacks": {
        "dump_stacks": true,
        "first_thread_only": true,
        "max_stack_size": 0
    },
    "maps": {
        "dump_by_name": [
            "[vdso]"
        ]
    },
    "compression": {
        "compressor": "gzip",
        "extension": "gz",
        "in_tar": true 
    },
    "dump_auxv_so_list": true,
    "dump_pthread_list": true,
    "dump_robust_mutex_list": true,
    "dump_scope": 1024,
    "live_dumper": false,
    "write_proc_info": false,
    "write_debug_log": false,
    "dump_fat_core": false
}

/////

It is a copy of a minicoredumper example with hardly any modification. We need the first_tread_only because our application can easily spawn 50+ threads with up to 1 MB stack each, and we don't dump other memory segments because our application can easily consume 60+ GB of memory. Since our crash dumps have to be transmitted from rural areas all around the world back to the Netherlands we like them small :)
 
> If this is reproducible, it would also be helpful to turn on:
> 
>      "write_proc_info": true,
> 
> Then we can at least see from which mapping it is trying to dump.

Thanks, I will enable the feature and come back to you when I get more info.

> The errno="Success" is irrelevant in this case. Failed reads are
> allowed. The question is: Why is it trying to read addresses that are
> not mapped to anything?

Good question. Although I don't think it works that way, can it be that if we try to access an invalid address (e.g. we try to read from an uninitialized pointer, or cause a stack overflow way outside the stack guard) that it accidently tries to read from unmapped memory for some reason ? Don't know whether it matters, but the application uses mlockall, swap is disabled, so all pages are present in main memory.

> 
> But I will also take a look at the code here and figure out what could
> be happening.

Thank you for your swift reply,

Jos Hulzink