Re: gdb "Core was generated by" truncated to 80 characters
Jonny Grant <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] so resending] > > [email protected] 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