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

[Jim Ingham]

Ah, I think I've seen python scripts out there to dump a crash log format list of the current threads, and the lldb.macosx.crashlog command knows how to parse and create a debug session from those files.  But that code is pretty much unrelated to the core file reading code. 

So while it would be interesting to test text-file crash log reading as a separate issue, it wouldn't test the core file reading code, which was what we were talking about in this thread.

Jim


> On Jul 30, 2015, at 11:29 AM, Zachary Turner <zturner at google.com> wrote:
> 
> Oh I must have misunderstood your earlier post.  I thought you were saying that the OSX crash reports (text based) was much smaller than 500MB, so I was asking if the debugger could produce and/or load those.
> 
> On Thu, Jul 30, 2015 at 11:25 AM Jim Ingham <jingham at apple.com> wrote:
> 
> > On Jul 30, 2015, at 11:17 AM, Zachary Turner <zturner at google.com> wrote:
> >
> > But can a user generate one of these from inside the debugger, transfer it to another machine, load it in the debugger and use it to diagnose a problem?  The easy portability of core dumps between machines has always been one of the best things about them on Windows.  I can just email someone a core file when their program crashes and they can load it up and take a look.  Not to mention that it makes testing easier, since we can check in core files all day long and not have a noticeable impact on the repo.
> 
> Yes, this all works, including preserving the UUID's of the loaded libraries so you can symbolicate the crashes after the fact.  Provided of course that you don't mind being mailed a 500MB file.
> 
> Jim
> 
> >
> > In any case, just an idea.  We'll probably check in dumps for testing the windows core file process plugin, so wherever possible we can try to come up with tests that are platform agnostic, but it would still be nice long term if it were possible to get better coverage on other platforms as well.
> >
> > On Thu, Jul 30, 2015 at 11:08 AM Jim Ingham <jingham at apple.com> wrote:
> > 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
> > >
> >
>