[lldb-dev] Question (bug?) about thread tids when lldb loads a core dump.

[Jim Ingham]

OS X crash reports are vended by a text crash log, which does contain hashes & load locations of all the libraries involved, and the backtraces of all the threads, and register state of the crashing thread.  In my experience this is usually good enough and if it isn't the core files seldom add that crucial missing detail, since that crucial missing detail was something that was true 30 seconds ago...

So I don't think the Core OS folks are likely to spend a lot of time worrying about the size of user space core files. 

Jim


> On Jul 30, 2015, at 10:44 AM, Zachary Turner <zturner at google.com> wrote:
> 
> Hmm, so the way this works on Windows is that inside the core file are the names of libraries along with a corresponding hash of the library.  When the core file is read, the debugger searches a pre-defined set of locations for symbol information for the libraries (a symbol file which claims to match the name and hash of the library written in the core).
> 
> Has any thought ever been given to doing something like this on Mac?  It seems a little wasteful to have every core file duplicate the same information about system libraries.
> 
> Even easier, what about a flag when generating a core that just says "don't write system libraries into the core"?  Sure, it might degrade the debugging experience, but I think there's still some basic things you can do without that information.
> 
> For Windows core file tests I had planned to just make these lightweight core files (in the windows universe these are called "minidumps"), which are usually less than 100KB.
> 
> On Thu, Jul 30, 2015 at 10:31 AM Jim Ingham <jingham at apple.com> wrote:
> User-level core files on Mac OS X are huge (500MB for a nothing app).  This is because most of the system libraries are munged into a unified "shared cache" and that gets written out in toto in the core.  Just a heads up...
> 
> Jim
> 
> > On Jul 30, 2015, at 9:58 AM, Ed Maste <emaste at freebsd.org> wrote:
> >
> > On 30 July 2015 at 12:14, Zachary Turner <zturner at google.com> wrote:
> >> Would be great if we had a test that verified this.  I think we could do
> >> this by making a small program that gets its own main thread id at runtime
> >> and stores it in a local variable.  Generate a core dump while stopped at a
> >> breakpoint right after the variable is initialized.  Then have the test
> >> verify that whatever command reports the current thread is has the same
> >> value as the variable.
> >
> > Yes, we definitely need tests. We've discussed core file tests a bit
> > in the past, but haven't come to a resolution as I recall.
> >
> > I'm not a fan of generating cores on the fly in the tests; we should
> > be able to test core loading for all supported targets, and I'd rather
> > not spam system logs with crash reports in order to run a test. I
> > think we could instead just commit a set of test executables and
> > associated core files to the repository. Some effort is probably
> > necessary to reduce the size of core files on certain operating
> > systems -- on FreeBSD we end up with core files of at least ~4MB, due
> > to malloc defaults.
> >
> > I started working on collecting userland core files from various
> > operating systems a while back:
> > https://github.com/emaste/userland-cores
> > I can take another look with a goal of producing a representative
> > sample that could be used for LLDB tests.
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>