gdb "Core was generated by" truncated to 80 characters

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

gdb "Core was generated by" truncated to 80 characters

Jonny Grant
[Not sure if this got through to [hidden email]  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

Reply | Threaded
Open this post in threaded view
|

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

Simon Marchi-4
On 2020-05-26 7:07 a.m., Jonny Grant wrote:
> [Not sure if this got through to [hidden email]  so resending]

[hidden email] 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
Reply | Threaded
Open this post in threaded view
|

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 [hidden email]  so resending]
>
> [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

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

Simon Marchi-4
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 [hidden email]  so resending]
>>
>> [hidden email] 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