<div dir="ltr">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.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jul 30, 2015 at 11:08 AM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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...<br>
<br>
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.<br>
<br>
Jim<br>
<br>
<br>
> On Jul 30, 2015, at 10:44 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> On Thu, Jul 30, 2015 at 10:31 AM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> 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...<br>
><br>
> Jim<br>
><br>
> > On Jul 30, 2015, at 9:58 AM, Ed Maste <<a href="mailto:emaste@freebsd.org" target="_blank">emaste@freebsd.org</a>> wrote:<br>
> ><br>
> > On 30 July 2015 at 12:14, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> >> Would be great if we had a test that verified this.  I think we could do<br>
> >> this by making a small program that gets its own main thread id at runtime<br>
> >> and stores it in a local variable.  Generate a core dump while stopped at a<br>
> >> breakpoint right after the variable is initialized.  Then have the test<br>
> >> verify that whatever command reports the current thread is has the same<br>
> >> value as the variable.<br>
> ><br>
> > Yes, we definitely need tests. We've discussed core file tests a bit<br>
> > in the past, but haven't come to a resolution as I recall.<br>
> ><br>
> > I'm not a fan of generating cores on the fly in the tests; we should<br>
> > be able to test core loading for all supported targets, and I'd rather<br>
> > not spam system logs with crash reports in order to run a test. I<br>
> > think we could instead just commit a set of test executables and<br>
> > associated core files to the repository. Some effort is probably<br>
> > necessary to reduce the size of core files on certain operating<br>
> > systems -- on FreeBSD we end up with core files of at least ~4MB, due<br>
> > to malloc defaults.<br>
> ><br>
> > I started working on collecting userland core files from various<br>
> > operating systems a while back:<br>
> > <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_emaste_userland-2Dcores&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=DDUMf06MYELAe1Nlv7KChiwJLLHbYha4jtK_AOiWqwQ&m=J-AT-_cNQrVGKLquNhuKsQdfbhfAsc9XHivCiHQ3b50&s=ISn99No9h0lwedpz8ujH7y3xfyI3Zq6HIbNQlIvcwIE&e=" rel="noreferrer" target="_blank">https://github.com/emaste/userland-cores</a><br>
> > I can take another look with a goal of producing a representative<br>
> > sample that could be used for LLDB tests.<br>
> > _______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
<br>
</blockquote></div>