gdb "Core was generated by" truncated to 80 characters

Jonny Grant
Sun Jun 7 22:27:57 GMT 2020

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  so resending]
> 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:

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

More information about the Gdb mailing list