gdb "Core was generated by" truncated to 80 characters

gdb "Core was generated by" truncated to 80 characters

[Jonny Grant]

[Not sure if this got through to bug-gdb@gnu.org  so resending]

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.

Sorry I know my gdb isn't the latest, it's Ubuntu LTS

I tried setting .gdbinit 'set width unlimited'
but the output is still truncated.

Example below

// gcc-8 -Wall -o signal signal.c


#include <signal.h>

int main()
{
raise(SIGTRAP);
return 0;
}




$ ./signal 
myverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglongfz
Trace/breakpoint trap (core dumped)
$
$ gdb -c core signal
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from signal...(no debugging symbols found)...done.
[New LWP 27437]
Core was generated by `./signal myverylonglonglongmyverylonglonglongmyverylonglonglongmyverylonglonglo'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 __GI_raise (sig=<optimised out>) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) q

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

[Simon Marchi]

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

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
...

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.

Simon

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

[Jonny Grant]

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

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

[Simon Marchi]

On 2020-06-07 6:27 p.m., Jonny Grant wrote:
> 
> 
> 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?

This is maintained in the Linux kernel.

https://www.kernel.org/doc/html/latest/process/development-process.html

Simon