Re: gdb "Core was generated by" truncated to 80 characters

[Jonny Grant <jg@jguk.org>]

On 26/05/2020 15:09, Simon Marchi wrote:
> On 2020-05-26 7:07 a.m., Jonny Grant wrote:
>> [Not sure if this got through to bug-gdb@gnu.org  so resending]
> 
> gdb@sourceware.org is the right place.
> 
>> Hello
>>
>> Just noticed my command line args of a core file are truncated, so it's hard to reproduce the crash as I don't know what the core was generated from.
>>
>> "Core was generated by" truncated to 80 characters in the below example.
>>
>> May I ask, is this a limitation of the kernel dump or gdb? When i use 'strings' I see the core does contain the full command line.
> 
> You see the name of the process as dumped by the kernel, which truncates it at
> a certain length.  Here's the corresponding code in the kernel, where you see it
> limited at 80 characters:
> 
> https://elixir.bootlin.com/linux/v5.6.14/source/include/uapi/linux/elfcore.h#L79

It's a shame that is so small, the arguments are visible when running I thought in ps aux. Do you know who is the 
maintainer of that file please?

I was going to proposed the comment is updated on this:
	char	pr_fname[16];	/* filename of executable */

changing the comment to
	char	pr_fname[16];	/* filename of executable with a NUL terminator */

My core has a truncated filename (pr_fname), so it ends up as ThreadPoolServi_S5.core for me here.


> You can inspect the note with eu-readelf:
> 
> $ eu-readelf -a ./core
> ...
>    CORE                 136  PRPSINFO
>      state: 0, sname: R, zomb: 0, nice: 0, flag: 0x0000000000400600
>      uid: 1000, gid: 1000, pid: 4049460, ppid: 3612973, pgrp: 4049460
>      sid: 3612973
>      fname: signal
>      psargs: ./signal myverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglo
> ...

Great, thank you.

I was checking on another core dump I have. ThreadPoolServi_S5.core

Unfortunately for me I don't have these 'psargs' on my ThreadPoolServi_S5.core file. I imagine it is a thread, and 
created by pthread_setname_np

although GDB manages to pull out as:

Core was generated by `/usr/lib/chromium-browser/chromium-browser --enable-pinch --log-level=0 --enabl'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.


> The complete "command line" you see with strings comes from the fact that
> the argument array (argv) is present somewhere in memory.  So if you are
> able to backtrace all the way to main, you might be able to print argc and
> argv and deduce the command line.  Even if you aren't able to do that, you
> could still do a bit of forensic to find out where the argv array is located
> and get the information.

It would be nice if ARGV was prefixed in the memory with something unique, so I could find with strings. unfortunately 
the ELF file has no symbols

Cheers, Jonny