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

blloyd blloyd at familyhonor.net
Sat Jun 7 03:58:16 UTC 2014


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.

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.




More information about the Openembedded-devel mailing list