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

[Jim Ingham]

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