Created attachment 492 [details] coredump file In 1.2 denzil, the pseudo-nativesdk will result a segmentation fault on 32bit FC16 x86. Steps to reproduce this: 1. extract poky-eglibc-i686-i586-meta-toolchain-gmae-1.2.tar.bz2 2. source /opt/poky/1.2/environment-setup-i586-poky-linux 3. runqemu-extract-sdk core-image-sato-sdk.tar.bz2 /tmp/abcdf a segmentation fault pseudo-nativesdk in pseudo-nativesdk will result in the failure of runqemu-extract-sdk. This also blocks the adt-installer. However, we don't see this on 32bit FC13 x86.
Does it just happen to FC16 32bit? And no other distro? How about FC16 64bit?
FC16 64bit and Ubuntu 64bit don't happen. But it weird on Opensuse 64bit, after run runqemu-extract-sdk, it freezed there for a long long time, anyway extracted successfully.
*** Bug 2353 has been marked as a duplicate of this bug. ***
I tried to gdb the coredump file: (gdb) set env LD_LIBRARY_PATH /opt/poky/1.2/sysroots/i686-pokysdk-linux/lib:/opt/poky/1.2/sysroots/i686-pokysdk-linux/usr/lib (gdb) file /bin/tar Reading symbols from /bin/tar...(no debugging symbols found)...done. Missing separate debuginfos, use: debuginfo-install tar-1.26-2.fc16.i686 (gdb) core-file ./core.13883 [New LWP 13883] warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Core was generated by `tar -C /tmp/x86-64 -xjf /home/tester/Downloads/denzil/adt-installer/download_im'. Program terminated with signal 11, Segmentation fault. #0 0xb754afda in __libc_start_main () from /opt/poky/1.2/sysroots/i686-pokysdk-linux/lib/libc.so.6 (gdb) bt #0 0xb754afda in __libc_start_main () from /opt/poky/1.2/sysroots/i686-pokysdk-linux/lib/libc.so.6 #1 0x0804bd41 in ?? () Backtrace stopped: Not enough registers or memory available to unwind further Seems to me an internal crash in eglibc-nativesdk 2.15 crashed on FC16 32bit.
I just found that on FC16 32bit, running the following command will also trigger a segmentation fault LD_LIBRARY_PATH=/opt/poky/1.2/sysroots/i686-pokysdk-linux/lib:/opt/poky/1.2/sysroots/i686-pokysdk-linux/usr/lib pwd any comment?
Seems the fix we introduced in fixing bug #2299 not solving the problem, I reopened it.
when run command "runqemu nfs ./zImage-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+dfbba772cbee84125ac1558c904a7dc181445f5f-r1-qemuarm-20120418165821.bin /buildarea/tester/test_rootfs/" on opensuse 12.1 x86_64, following error is found when run "dmesg": .... [ 1610.789444] pseudo[27930]: segfault at 0 ip (null) sp 00007fffdc71d2c8 error 14 in bash[400000+9a000] ... qemu target can not boot up ("/buildarea/tester/test_rootfs/" dir is from "runqemu-extract-sdk"). git info :2c3d4f5beee8f57a74244495511b9294df1085ea git branch : poky/denzil test env: host: opensuse 12.1 x86_64 kernel: 3.1.9-1.4-desktop #1 SMP PREEMPT
On openSuse 12.1 x86_64, we compared the 2 extracted rootfs using pseudo-native and pseudo-nativesdk, the difference is that several pseudo database files under ${rootfs}/var/pseudo/pseudothe are missing in the rootfs extracted by pseudo-nativesdk. We guess this might be the reason why the qemu launching failed. (In reply to comment #7) > when run command "runqemu nfs > ./zImage-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+dfbba772cbee84125ac1558c904a7dc181445f5f-r1-qemuarm-20120418165821.bin > /buildarea/tester/test_rootfs/" on opensuse 12.1 x86_64, following error is > found when run "dmesg": > > .... > [ 1610.789444] pseudo[27930]: segfault at 0 ip (null) sp > 00007fffdc71d2c8 error 14 in bash[400000+9a000] > ... > > qemu target can not boot up ("/buildarea/tester/test_rootfs/" dir is from > "runqemu-extract-sdk"). > > git info :2c3d4f5beee8f57a74244495511b9294df1085ea > git branch : poky/denzil > > test env: > host: opensuse 12.1 x86_64 > kernel: 3.1.9-1.4-desktop #1 SMP PREEMPT
I am pretty sure we have two separate issues here. One is segfaults which are occurring when host system binaries get run with our ld.so or libc. The other is the pseudo database issue. There should be no circumstances under which an absent database causes a segfault for pseudo; it is pretty robust about missing files, all it does is report the native filesystem's type/uid/gid.
(In reply to comment #9) > I am pretty sure we have two separate issues here. One is segfaults which are > occurring when host system binaries get run with our ld.so or libc. The other > is the pseudo database issue. Seems on FC16 32bit, our eglibc-nativesdk 2.15 can NOT be loaded by the native ld.so. $ LD_PRELOAD=/opt/poky/1.2/sysroots/i686-pokysdk-linux/lib/libc.so.6 /bin/pwd Segmentation fault (core dumped) > There should be no circumstances under which an absent database causes a > segfault for pseudo; it is pretty robust about missing files, all it does is > report the native filesystem's type/uid/gid.
(In reply to comment #10) > (In reply to comment #9) > > I am pretty sure we have two separate issues here. One is segfaults which are > > occurring when host system binaries get run with our ld.so or libc. The other > > is the pseudo database issue. > > Seems on FC16 32bit, our eglibc-nativesdk 2.15 can NOT be loaded by the native > ld.so. > > $ LD_PRELOAD=/opt/poky/1.2/sysroots/i686-pokysdk-linux/lib/libc.so.6 /bin/pwd > Segmentation fault (core dumped) > Confirmed that eglibc-nativesdk 2.13 can NOT be loaded by the host system ld.so on FC16 32bit either. However, on FC13 32bit, both 2.13/2.15 eglibc-nativesdk can be loaded by the host system ld.so.
Hmm, this makes sense. Whilst we're using the 2.15 libc.so, the path to the loader is hardcoded into the binary and we can't change this. It will therefor always use the host version. It makes you wonder what is special causing those particular loaders to fail, the fact 2.13 can't load our 2.13 nativesdk is very interesting. This basically implies we can't run host binaries under pseudo unless we fix this. Our options are therefore: a) Make a list of the things we execute under pseudo and make sure meta-toolchain provides them (like tar-nativesdk). Extremely ugly. b) Try and figure out why the loaders are incompatible in some cases. I wonder if there are libc patches applied which cause this? We could revert the eglibc-nativesdk upgrade but I think that just hides the problems and breaks a different set of distributions :(.
Fixed in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=604fc2adce743294cbad631993ce17e7bfcf17ab and also applied to the denzil branch
Got fixed and verify on poky/denzil:35196ff703726addf7f4051ee09d70bf9ee0c5d0
(In reply to comment #7) > when run command "runqemu nfs > ./zImage-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+dfbba772cbee84125ac1558c904a7dc181445f5f-r1-qemuarm-20120418165821.bin > /buildarea/tester/test_rootfs/" on opensuse 12.1 x86_64, following error is > found when run "dmesg": > > .... > [ 1610.789444] pseudo[27930]: segfault at 0 ip (null) sp > 00007fffdc71d2c8 error 14 in bash[400000+9a000] > ... > > qemu target can not boot up ("/buildarea/tester/test_rootfs/" dir is from > "runqemu-extract-sdk"). > > git info :2c3d4f5beee8f57a74244495511b9294df1085ea > git branch : poky/denzil > > test env: > host: opensuse 12.1 x86_64 > kernel: 3.1.9-1.4-desktop #1 SMP PREEMPT using nightly build 20120423-1 (1.2 M4 RC5), the above error not met, qemu target now can boot normally on opensuse 12.1 hosts. git info : 35196ff703726addf7f4051ee09d70bf9ee0c5d0 git branch : poky/denzil