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

[Zachary Turner]

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
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150730/db448377/attachment.html>