[minicoredumper] Invalid stack when all memory regions are dumped

[Abhi Arjun]

Hi John Ogness,
   Thanks for your reply. 

   Now I'm able to get the stack trace, however gdb is throwing truncated core warning message.  

   (gdb) core core
BFD: warning: /usr/local/var/crash/minicoredumper/a.out.20210723.232438+0530.15342/core is truncated: expected core file size >= 389120, found: 385484
[New LWP 15342]

I modified program to include global variable and added corresponding global var memory region in recept file, but now again stack is not showing properly. Global variable value is displayed properly by GDB. 

Below are the details:
GDB log:
=======

(gdb) core core
BFD: warning: /usr/local/var/crash/minicoredumper/global.20210723.234922+0530.15954/core is truncated: expected core file size >= 389120, found: 385484
[New LWP 15954]
Core was generated by `./global'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f2a1dc91675 in ?? ()
(gdb) bt
#0  0x00007f2a1dc91675 in ?? ()
#1  0x00007f2a1db81e95 in ?? ()
#2  0x00007f2a1dd4c9e8 in ?? ()
#3  0x0000000000000000 in ?? ()
(gdb) p x
$1 = 20

C Program:
=========
$cat global.c 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int x=10;
int main()
{
    char *ptr = (char *)5;

    x=20;
    printf("&x=%p\tx=%d\n", &x, x);
    printf("Test Program:%s\n", ptr);
}

Recept file (only showing maps section)
===============================
"maps": {
        "dump_by_name": [
            "[vdso]",
            "/home/abhiarjun/mini/global",
            ""
        ]
    },
Regards,
Abi

Jul 23, 2021, 13:54 by john.ogness at linutronix.de:

> Hi Abi
>
> On 2021-07-22, Abhi Arjun <abhiarjun at tutanota.com> wrote:
>
>> Where you able to investigate and figure out the issue?
>>
>
> I can see where the problem is occurring, but I do not yet understand
> why it is a problem. It will take some time to get this one.
>
>> If it takes time, can I go back to old version of minicoredumper where
>> stack is interpreted properly by gdb.
>>
>
> I expect all versions of the minicoredumper will have this problem. The
> workaround is not to use "*" when setting "dump_by_name". It should be
> enough for you to specify the pseudo-path and anonymous mappings. (You
> do not need to specify the stack because minicoredumper has dedicated
> settings for that.)
>
>  "maps": {
>  "dump_by_name": [
>  "[vdso]",
>  "[heap]",
>  "[vvar]",
>  "",
>  ]
>  }
>
> Please test if this is enough for your needs.
>
> The problem is occurring due to the file mappings, which are matched
> when you use "*" here. I will continue investigating this issue.
>
>> I couldn't find older versions of minicoredumper in the home page.
>>
>
> Here are the links to older versions. But I do not think you will find
> that helpful. And I expect that they suffer from the exact same problem:
>
> https://linutronix.de/minicoredumper/files/minicoredumper-2.0.0.tar.xz
> https://linutronix.de/minicoredumper/files/minicoredumper-1.0.2.tar.gz
> https://linutronix.de/minicoredumper/files/minicoredumper-1.0.1.tar.gz
> https://linutronix.de/minicoredumper/files/minicoredumper-1.0.0.tar.gz
>
> John Ogness
>