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 <jing...@apple.com> wrote: > > > On Jul 30, 2015, at 11:17 AM, Zachary Turner <ztur...@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 <jing...@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 <ztur...@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 <jing...@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 <ema...@freebsd.org> wrote: > > > > > > > > On 30 July 2015 at 12:14, Zachary Turner <ztur...@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@cs.uiuc.edu > > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
