[oe] multi-threaded core dump issues when threading symbols missing

[Khem Raj]

On Fri, Jun 6, 2014 at 8:58 PM, blloyd <blloyd at familyhonor.net> wrote:
> I originally tried to solve this problem a long time ago by changing the gdb
> package to depend on the selected libc debug packages.  That never did get
> to a state that was accepted for commit.
>
> However, even if it did, I've come to realize that it wouldn't really fix
> the problem.
>
> Basically, core dumps do not generate valid dumps for multiple threads when
> the threading debug symbols are not available.  This includes automatically
> generated core dumps when an application segfaults while running (kernel
> generated dumps).
>
> Two possible solutions for the problem which will ensure core dumps work
> when enabled is to:
> 1.  not strip the libc packages.  Since this would mean more loaded into
> memory all the time, I can understand why this may not be desirable.
> 2.  Include the debug symbols for either all of libc or just the specific
> libc debug symbols needed for a valid core dump so that core dumps work.
>      a.  Just have eglibc depend on eglibc-dbg and uclibc depend on
> uclibc-dbg.  Easy.  For eglibc, this adds @35mb to a system
>      b.  Split the required *.so.debug out from the rest of the dbg, and
> have the -dbg package and base package depend on the new package.  I believe
> the minimal required is libpthread-*.so.debug, which for the eglibc case
> adds less than 1MB to the image.
>
> Testing would be required to ensure the right subset is selected for 2.b,
> but when I originally did this just adding that one debug file caused the
> generated images to work for all my debugging needs.
>
> Are either of the above possible solutions likely to get approved?  I don't
> mind implementing either, but as they effectively affect every image made, I
> would like to discuss before implementing one of the solutions.
>
> Without this change, a debug dump will have only one viewable thread.  It is
> not usually the crashing thread.  With the required debug symbols in place,
> crash dump debugging (including on a development box with the device SDK
> installed) appears to function properly.
>
>
> Any suggestions about what can be done that could be accepted for inclusion
> into the mainline after completion would be appreciated.

what happens if you install eglibc-thread-db ? does that solve the problem

>
> Is 1MB worth worrying about?  I know some images that are generated are very
> small, but I don't usually get things smaller than 200MB where 500K is just
> noise.
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel