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 <[email protected]> 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 <[email protected]> wrote: > > > On Jul 30, 2015, at 11:17 AM, Zachary Turner <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > > On 30 July 2015 at 12:14, Zachary Turner <[email protected]> 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 > > > > [email protected] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
