* Problem with new image-prelink
@ 2011-09-09 3:34 James Limbouris
2011-09-09 15:57 ` Mark Hatle
0 siblings, 1 reply; 10+ messages in thread
From: James Limbouris @ 2011-09-09 3:34 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
Hi,
After the new version of prelink was committed, I started experiencing
segmentation faults in a large Qt app on my prelinked image.
They go away when image-prelink is disabled, or the single binary is
reinstalled with opkg. I am using eglibc 2.12 and gcc 4.5. Is anyone
else having trouble?
Strace shows the binary gets through a lot of library loads. Here is the tail
end before the crash:
open("/usr/lib/libQtDBusE.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\274n\1D4\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=499692, ...}) = 0
mmap2(0x44000000, 497232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x44000000
mmap2(0x44078000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x78) = 0x44078000
close(3) = 0
open("/usr/lib/libpng12.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\370\266\215A4\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=130844, ...}) = 0
mmap2(0x418d8000, 160984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x418d8000
mprotect(0x418f8000, 28672, PROT_NONE) = 0
mmap2(0x418ff000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f) = 0x418ff000
close(3) = 0
open("/usr/lib/libfreetype.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\310\366\5B4\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=458292, ...}) = 0
mmap2(0x42058000, 488488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x42058000
mprotect(0x420c5000, 28672, PROT_NONE) = 0
mmap2(0x420cc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6c) = 0x420cc000
close(3) = 0
open("/usr/lib/libQtXmlE.so.4", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\364,\20B4\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=268336, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000
mmap2(0x420f0000, 297992, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x420f0000
mprotect(0x42130000, 28672, PROT_NONE) = 0
mmap2(0x42137000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3f) = 0x42137000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40008000
set_tls(0x40008860, 0x40008f48, 0x415a4048, 0x40008860, 0x415a4048) = 0
mprotect(0x416f3000, 4096, PROT_READ) = 0
mprotect(0x41c29000, 12288, PROT_READ) = 0
mprotect(0x416cd000, 8192, PROT_READ) = 0
mprotect(0x417d1000, 4096, PROT_READ) = 0
mprotect(0x417e5000, 4096, PROT_READ) = 0
mprotect(0x4179d000, 4096, PROT_READ) = 0
mprotect(0x415a3000, 4096, PROT_READ) = 0
munmap(0x40001000, 5103) = 0
set_tid_address(0x40008408) = 1235
set_robust_list(0x40008410, 0xc) = 0
rt_sigaction(SIGRTMIN, {0x416dc084, [], SA_SIGINFO|0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x416dbf28, [], SA_RESTART|SA_SIGINFO|0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
brk(0) = 0x1c5000
brk(0x1e6000) = 0x1e6000
open("/proc/self/auxv", O_RDONLY) = 3
read(3, "\20\0\0\0\227\1\0\0", 8) = 8
close(3) = 0
sched_getparam(1235, { 0 }) = 0
sched_getscheduler(1235) = 0 (SCHED_OTHER)
clock_getres(CLOCK_MONOTONIC, {0, 1}) = 0
sched_get_priority_min(SCHED_OTHER) = 0
sched_get_priority_max(SCHED_OTHER) = 0
sched_get_priority_max(SCHED_OTHER) = 0
gettimeofday({1315537291, 101290}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault
It should have continued with:
open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/locale.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
clock_gettime(CLOCK_MONOTONIC, {645, 655570927}) = 0
futex(0x417d20a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
uname({sys="Linux", node="192.168.1.14", ...}) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3) = 0
socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
close(3) = 0
open("/etc/nsswitch.conf", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000
read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
read(3, "", 4096) = 0
close(3) = 0
munmap(0x40001000, 4096) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5103, ...}) = 0
mmap2(NULL, 5103, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40001000
close(3) = 0
open("/lib/libnss_compat.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0T\r\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=26368, ...}) = 0
mmap2(NULL, 57952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40009000
mprotect(0x4000f000, 28672, PROT_NONE) = 0
mmap2(0x40016000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0x40016000
close(3)
.....
I think the gettimeofday() before the crash is the end of the loading process.
None of the other binaries on the system are doing this - even demos from
qt4-embedded-demos. The only salient feature of this particular binary is
its large resource section, weighing it in at 1.4 MB.
I'm rebuilding now with eglibc 2.13 and gcc 4.6. Will report the results.
Regards,
James Limbouris
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: Problem with new image-prelink 2011-09-09 3:34 Problem with new image-prelink James Limbouris @ 2011-09-09 15:57 ` Mark Hatle 2011-09-12 1:39 ` James Limbouris 0 siblings, 1 reply; 10+ messages in thread From: Mark Hatle @ 2011-09-09 15:57 UTC (permalink / raw) To: openembedded-core Which architecture? I know of a few issues on MIPS, but they should simply prevent prelinking instead of causing problems. Also, can you check your log.do_rootfs for the failed image. Look for any prelinker warnings or errors. (Easiest way is to search for "prelink". There should be two hits, one that says "Size before prelinking: ..." and one that says "Size after prelinking: ..." between that would be any prelinker messages.) --Mark On 9/8/11 10:34 PM, James Limbouris wrote: > Hi, > > After the new version of prelink was committed, I started experiencing > segmentation faults in a large Qt app on my prelinked image. > They go away when image-prelink is disabled, or the single binary is > reinstalled with opkg. I am using eglibc 2.12 and gcc 4.5. Is anyone > else having trouble? > > Strace shows the binary gets through a lot of library loads. Here is the tail > end before the crash: > > open("/usr/lib/libQtDBusE.so.4", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\274n\1D4\0\0\0"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=499692, ...}) = 0 > mmap2(0x44000000, 497232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x44000000 > mmap2(0x44078000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x78) = 0x44078000 > close(3) = 0 > open("/usr/lib/libpng12.so.0", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\370\266\215A4\0\0\0"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=130844, ...}) = 0 > mmap2(0x418d8000, 160984, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x418d8000 > mprotect(0x418f8000, 28672, PROT_NONE) = 0 > mmap2(0x418ff000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f) = 0x418ff000 > close(3) = 0 > open("/usr/lib/libfreetype.so.6", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\310\366\5B4\0\0\0"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=458292, ...}) = 0 > mmap2(0x42058000, 488488, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x42058000 > mprotect(0x420c5000, 28672, PROT_NONE) = 0 > mmap2(0x420cc000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6c) = 0x420cc000 > close(3) = 0 > open("/usr/lib/libQtXmlE.so.4", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\364,\20B4\0\0\0"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=268336, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 > mmap2(0x420f0000, 297992, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x420f0000 > mprotect(0x42130000, 28672, PROT_NONE) = 0 > mmap2(0x42137000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3f) = 0x42137000 > close(3) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40008000 > set_tls(0x40008860, 0x40008f48, 0x415a4048, 0x40008860, 0x415a4048) = 0 > mprotect(0x416f3000, 4096, PROT_READ) = 0 > mprotect(0x41c29000, 12288, PROT_READ) = 0 > mprotect(0x416cd000, 8192, PROT_READ) = 0 > mprotect(0x417d1000, 4096, PROT_READ) = 0 > mprotect(0x417e5000, 4096, PROT_READ) = 0 > mprotect(0x4179d000, 4096, PROT_READ) = 0 > mprotect(0x415a3000, 4096, PROT_READ) = 0 > munmap(0x40001000, 5103) = 0 > set_tid_address(0x40008408) = 1235 > set_robust_list(0x40008410, 0xc) = 0 > rt_sigaction(SIGRTMIN, {0x416dc084, [], SA_SIGINFO|0x4000000}, NULL, 8) = 0 > rt_sigaction(SIGRT_1, {0x416dbf28, [], SA_RESTART|SA_SIGINFO|0x4000000}, NULL, 8) = 0 > rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 > getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 > brk(0) = 0x1c5000 > brk(0x1e6000) = 0x1e6000 > open("/proc/self/auxv", O_RDONLY) = 3 > read(3, "\20\0\0\0\227\1\0\0", 8) = 8 > close(3) = 0 > sched_getparam(1235, { 0 }) = 0 > sched_getscheduler(1235) = 0 (SCHED_OTHER) > clock_getres(CLOCK_MONOTONIC, {0, 1}) = 0 > sched_get_priority_min(SCHED_OTHER) = 0 > sched_get_priority_max(SCHED_OTHER) = 0 > sched_get_priority_max(SCHED_OTHER) = 0 > gettimeofday({1315537291, 101290}, NULL) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > Segmentation fault > > > It should have continued with: > > > open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) > open("/usr/share/locale/locale.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) > clock_gettime(CLOCK_MONOTONIC, {645, 655570927}) = 0 > futex(0x417d20a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > uname({sys="Linux", node="192.168.1.14", ...}) = 0 > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) > close(3) = 0 > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) > close(3) = 0 > open("/etc/nsswitch.conf", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000 > read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465 > read(3, "", 4096) = 0 > close(3) = 0 > munmap(0x40001000, 4096) = 0 > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=5103, ...}) = 0 > mmap2(NULL, 5103, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40001000 > close(3) = 0 > open("/lib/libnss_compat.so.2", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0T\r\0\0004\0\0\0"..., 512) = 512 > fstat64(3, {st_mode=S_IFREG|0755, st_size=26368, ...}) = 0 > mmap2(NULL, 57952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40009000 > mprotect(0x4000f000, 28672, PROT_NONE) = 0 > mmap2(0x40016000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0x40016000 > close(3) > ..... > > I think the gettimeofday() before the crash is the end of the loading process. > None of the other binaries on the system are doing this - even demos from > qt4-embedded-demos. The only salient feature of this particular binary is > its large resource section, weighing it in at 1.4 MB. > > I'm rebuilding now with eglibc 2.13 and gcc 4.6. Will report the results. > > Regards, > James Limbouris > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-09 15:57 ` Mark Hatle @ 2011-09-12 1:39 ` James Limbouris 2011-09-12 14:50 ` Mark Hatle 0 siblings, 1 reply; 10+ messages in thread From: James Limbouris @ 2011-09-12 1:39 UTC (permalink / raw) To: Patches and discussions about the oe-core layer > -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Mark Hatle > Sent: Friday, 9 September 2011 11:58 PM > To: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Problem with new image-prelink > > Which architecture? > > I know of a few issues on MIPS, but they should simply prevent prelinking > instead of causing problems. > > Also, can you check your log.do_rootfs for the failed image. Look for any > prelinker warnings or errors. (Easiest way is to search for "prelink". There > should be two hits, one that says "Size before prelinking: ..." and one that > says "Size after prelinking: ..." between that would be any prelinker messages.) > > --Mark > > On 9/8/11 10:34 PM, James Limbouris wrote: > > Hi, > > > > After the new version of prelink was committed, I started experiencing > > segmentation faults in a large Qt app on my prelinked image. > > They go away when image-prelink is disabled, or the single binary is > > reinstalled with opkg. I am using eglibc 2.12 and gcc 4.5. Is anyone > > else having trouble? > > > > Strace shows the binary gets through a lot of library loads. Here is the tail > > end before the crash: > > > > open("/usr/lib/libQtDBusE.so.4", O_RDONLY) = 3 > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\274n\1D4\0\0\0"..., 512) = > 512 > > fstat64(3, {st_mode=S_IFREG|0755, st_size=499692, ...}) = 0 > > mmap2(0x44000000, 497232, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x44000000 > > mmap2(0x44078000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x78) = 0x44078000 > > close(3) = 0 > > open("/usr/lib/libpng12.so.0", O_RDONLY) = 3 > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\370\266\215A4\0\0\0"..., > 512) = 512 > > fstat64(3, {st_mode=S_IFREG|0755, st_size=130844, ...}) = 0 > > mmap2(0x418d8000, 160984, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x418d8000 > > mprotect(0x418f8000, 28672, PROT_NONE) = 0 > > mmap2(0x418ff000, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f) = 0x418ff000 > > close(3) = 0 > > open("/usr/lib/libfreetype.so.6", O_RDONLY) = 3 > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\310\366\5B4\0\0\0"..., 512) > = 512 > > fstat64(3, {st_mode=S_IFREG|0755, st_size=458292, ...}) = 0 > > mmap2(0x42058000, 488488, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x42058000 > > mprotect(0x420c5000, 28672, PROT_NONE) = 0 > > mmap2(0x420cc000, 16384, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6c) = 0x420cc000 > > close(3) = 0 > > open("/usr/lib/libQtXmlE.so.4", O_RDONLY) = 3 > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\364,\20B4\0\0\0"..., 512) = > 512 > > fstat64(3, {st_mode=S_IFREG|0755, st_size=268336, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 > > mmap2(0x420f0000, 297992, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x420f0000 > > mprotect(0x42130000, 28672, PROT_NONE) = 0 > > mmap2(0x42137000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3f) = 0x42137000 > > close(3) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40008000 > > set_tls(0x40008860, 0x40008f48, 0x415a4048, 0x40008860, 0x415a4048) = 0 > > mprotect(0x416f3000, 4096, PROT_READ) = 0 > > mprotect(0x41c29000, 12288, PROT_READ) = 0 > > mprotect(0x416cd000, 8192, PROT_READ) = 0 > > mprotect(0x417d1000, 4096, PROT_READ) = 0 > > mprotect(0x417e5000, 4096, PROT_READ) = 0 > > mprotect(0x4179d000, 4096, PROT_READ) = 0 > > mprotect(0x415a3000, 4096, PROT_READ) = 0 > > munmap(0x40001000, 5103) = 0 > > set_tid_address(0x40008408) = 1235 > > set_robust_list(0x40008410, 0xc) = 0 > > rt_sigaction(SIGRTMIN, {0x416dc084, [], SA_SIGINFO|0x4000000}, NULL, 8) = > 0 > > rt_sigaction(SIGRT_1, {0x416dbf28, [], SA_RESTART|SA_SIGINFO|0x4000000}, > NULL, 8) = 0 > > rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 > > getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = > 0 > > brk(0) = 0x1c5000 > > brk(0x1e6000) = 0x1e6000 > > open("/proc/self/auxv", O_RDONLY) = 3 > > read(3, "\20\0\0\0\227\1\0\0", 8) = 8 > > close(3) = 0 > > sched_getparam(1235, { 0 }) = 0 > > sched_getscheduler(1235) = 0 (SCHED_OTHER) > > clock_getres(CLOCK_MONOTONIC, {0, 1}) = 0 > > sched_get_priority_min(SCHED_OTHER) = 0 > > sched_get_priority_max(SCHED_OTHER) = 0 > > sched_get_priority_max(SCHED_OTHER) = 0 > > gettimeofday({1315537291, 101290}, NULL) = 0 > > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > > +++ killed by SIGSEGV +++ > > Segmentation fault > > > > > > It should have continued with: > > > > > > open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No > such file or directory) > > open("/usr/share/locale/locale.alias", O_RDONLY|O_LARGEFILE) = -1 > ENOENT (No such file or directory) > > clock_gettime(CLOCK_MONOTONIC, {645, 655570927}) = 0 > > futex(0x417d20a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > > uname({sys="Linux", node="192.168.1.14", ...}) = 0 > > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 > ENOENT (No such file or directory) > > close(3) = 0 > > socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 > > connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 > ENOENT (No such file or directory) > > close(3) = 0 > > open("/etc/nsswitch.conf", O_RDONLY) = 3 > > fstat64(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 > > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000 > > read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465 > > read(3, "", 4096) = 0 > > close(3) = 0 > > munmap(0x40001000, 4096) = 0 > > open("/etc/ld.so.cache", O_RDONLY) = 3 > > fstat64(3, {st_mode=S_IFREG|0644, st_size=5103, ...}) = 0 > > mmap2(NULL, 5103, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40001000 > > close(3) = 0 > > open("/lib/libnss_compat.so.2", O_RDONLY) = 3 > > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0T\r\0\0004\0\0\0"..., 512) = > 512 > > fstat64(3, {st_mode=S_IFREG|0755, st_size=26368, ...}) = 0 > > mmap2(NULL, 57952, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40009000 > > mprotect(0x4000f000, 28672, PROT_NONE) = 0 > > mmap2(0x40016000, 8192, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0x40016000 > > close(3) > > ..... > > > > I think the gettimeofday() before the crash is the end of the loading process. > > None of the other binaries on the system are doing this - even demos from > > qt4-embedded-demos. The only salient feature of this particular binary is > > its large resource section, weighing it in at 1.4 MB. > > > > I'm rebuilding now with eglibc 2.13 and gcc 4.6. Will report the results. > > > > Regards, > > James Limbouris Hi Mark, The host is a 32 bit only i686, and the target is an armv5te. There are no prelinker errors in the log, and I get the same results with gcc 4.6 and eglibc 2.13. I've also tried installing prelink on the target, but it seems broken: root@192:~# opkg install prelink Installing prelink (1.0+git1+964f6eba613bf1c791a2a0b858cd044f05e2f151-r6) to root... Downloading http://192.168.1.11/oe-repo/armv5te/prelink_1.0+git1+964f6eba613bf1c791a2a0b858cd044f05e2f151-r6_armv5te.ipk. Installing elfutils (0.148-r3) to root... Downloading http://192.168.1.11/oe-repo/armv5te/elfutils_0.148-r3_armv5te.ipk. Configuring elfutils. Configuring prelink. [ 1680.130000] Alignment trap: prelink-rtld (1410) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-objdump: Recorded 6 dependencies, now seeing -1 [ 1680.210000] Alignment trap: prelink-rtld (1411) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/sbin/prelink: Recorded 4 dependencies, now seeing -1 [ 1680.280000] Alignment trap: prelink-rtld (1412) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/execstack: Recorded 4 dependencies, now seeing -1 [ 1680.360000] Alignment trap: prelink-rtld (1413) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-strings: Recorded 4 dependencies, now seeing -1 [ 1680.430000] Alignment trap: prelink-rtld (1414) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-elflint: Recorded 5 dependencies, now seeing -1 [ 1680.510000] Alignment trap: prelink-rtld (1415) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-findtextrel: Recorded 8 dependencies, now seeing -1 [ 1680.580000] Alignment trap: prelink-rtld (1416) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-elfcmp: Recorded 5 dependencies, now seeing -1 [ 1680.660000] Alignment trap: prelink-rtld (1417) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-ranlib: Recorded 4 dependencies, now seeing -1 [ 1680.730000] Alignment trap: prelink-rtld (1418) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-ar: Recorded 4 dependencies, now seeing -1 [ 1680.810000] Alignment trap: prelink-rtld (1419) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/eu-unstrip: Recorded 8 dependencies, now seeing -1 [ 1680.890000] Alignment trap: prelink-rtld (1420) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /usr/bin/rica5: Recorded 27 dependencies, now seeing -1 /usr/bin/rica5 above is the binary that segfaults when prelinked on the host. In the above, I first reinstalled it from an opkg, so that it would be unprelinked, hence the prelinking attempt above. root@192:~# prelink -a [ 1768.720000] Alignment trap: prelink-rtld (1422) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 prelink: /sbin/halt.sysvinit: Dependency tracing failed .... the same message and alignment trap are printed for 115 other binaries. Regards, James Limbouris ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-12 1:39 ` James Limbouris @ 2011-09-12 14:50 ` Mark Hatle 2011-09-13 2:58 ` James Limbouris 0 siblings, 1 reply; 10+ messages in thread From: Mark Hatle @ 2011-09-12 14:50 UTC (permalink / raw) To: openembedded-core Once the Linux Foundation servers come back on-line, I'll file a bug in the bugzilla.yoctoproject.org bug tracker. Hopefully this is something fairly simple, and fixing the target prelink-rtld will also resolve the failed prelinking for the QT binary. I hope to get to investigating this tomorrow. If you have time, you should be able to capture a core, or use gdb on the target and figure out where the bad alignment trap is occurring. The failure is in the "prelink-rtld" binary. Most likely when it's being run using: RTLD_WARN= RTLD_TRACE_PRELINKING=1 prelink-rtld <binary> That should fail with the same unaligned access.. Once that works and no longer fails.... it should produce the same output as if you ran: LD_WARN= LD_TRACE_LOADED_OBJECTS=1 LD_TRACE_PRELINKING=1 LD_BIND_NOW=1 /lib/ld-linux.so.3 <binary> (/lib/ld-linux.so.3 is from memory so I may be wrong..) Any deviation between the two could point to an alternative cause to the QT failure as well. --Mark On 9/11/11 8:39 PM, James Limbouris wrote: >> -----Original Message----- >> From: openembedded-core-bounces@lists.openembedded.org >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of >> Mark Hatle >> Sent: Friday, 9 September 2011 11:58 PM >> To: openembedded-core@lists.openembedded.org >> Subject: Re: [OE-core] Problem with new image-prelink >> >> Which architecture? >> >> I know of a few issues on MIPS, but they should simply prevent prelinking >> instead of causing problems. >> >> Also, can you check your log.do_rootfs for the failed image. Look for any >> prelinker warnings or errors. (Easiest way is to search for "prelink". There >> should be two hits, one that says "Size before prelinking: ..." and one that >> says "Size after prelinking: ..." between that would be any prelinker messages.) >> >> --Mark >> >> On 9/8/11 10:34 PM, James Limbouris wrote: >>> Hi, >>> >>> After the new version of prelink was committed, I started experiencing >>> segmentation faults in a large Qt app on my prelinked image. >>> They go away when image-prelink is disabled, or the single binary is >>> reinstalled with opkg. I am using eglibc 2.12 and gcc 4.5. Is anyone >>> else having trouble? >>> >>> Strace shows the binary gets through a lot of library loads. Here is the tail >>> end before the crash: >>> >>> open("/usr/lib/libQtDBusE.so.4", O_RDONLY) = 3 >>> read(3, >> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\274n\1D4\0\0\0"..., 512) = >> 512 >>> fstat64(3, {st_mode=S_IFREG|0755, st_size=499692, ...}) = 0 >>> mmap2(0x44000000, 497232, PROT_READ|PROT_EXEC, >> MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x44000000 >>> mmap2(0x44078000, 8192, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x78) = 0x44078000 >>> close(3) = 0 >>> open("/usr/lib/libpng12.so.0", O_RDONLY) = 3 >>> read(3, >> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\370\266\215A4\0\0\0"..., >> 512) = 512 >>> fstat64(3, {st_mode=S_IFREG|0755, st_size=130844, ...}) = 0 >>> mmap2(0x418d8000, 160984, PROT_READ|PROT_EXEC, >> MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x418d8000 >>> mprotect(0x418f8000, 28672, PROT_NONE) = 0 >>> mmap2(0x418ff000, 4096, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1f) = 0x418ff000 >>> close(3) = 0 >>> open("/usr/lib/libfreetype.so.6", O_RDONLY) = 3 >>> read(3, >> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\310\366\5B4\0\0\0"..., 512) >> = 512 >>> fstat64(3, {st_mode=S_IFREG|0755, st_size=458292, ...}) = 0 >>> mmap2(0x42058000, 488488, PROT_READ|PROT_EXEC, >> MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x42058000 >>> mprotect(0x420c5000, 28672, PROT_NONE) = 0 >>> mmap2(0x420cc000, 16384, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6c) = 0x420cc000 >>> close(3) = 0 >>> open("/usr/lib/libQtXmlE.so.4", O_RDONLY) = 3 >>> read(3, >> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\364,\20B4\0\0\0"..., 512) = >> 512 >>> fstat64(3, {st_mode=S_IFREG|0755, st_size=268336, ...}) = 0 >>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000 >>> mmap2(0x420f0000, 297992, PROT_READ|PROT_EXEC, >> MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x420f0000 >>> mprotect(0x42130000, 28672, PROT_NONE) = 0 >>> mmap2(0x42137000, 8192, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3f) = 0x42137000 >>> close(3) = 0 >>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40008000 >>> set_tls(0x40008860, 0x40008f48, 0x415a4048, 0x40008860, 0x415a4048) = 0 >>> mprotect(0x416f3000, 4096, PROT_READ) = 0 >>> mprotect(0x41c29000, 12288, PROT_READ) = 0 >>> mprotect(0x416cd000, 8192, PROT_READ) = 0 >>> mprotect(0x417d1000, 4096, PROT_READ) = 0 >>> mprotect(0x417e5000, 4096, PROT_READ) = 0 >>> mprotect(0x4179d000, 4096, PROT_READ) = 0 >>> mprotect(0x415a3000, 4096, PROT_READ) = 0 >>> munmap(0x40001000, 5103) = 0 >>> set_tid_address(0x40008408) = 1235 >>> set_robust_list(0x40008410, 0xc) = 0 >>> rt_sigaction(SIGRTMIN, {0x416dc084, [], SA_SIGINFO|0x4000000}, NULL, 8) = >> 0 >>> rt_sigaction(SIGRT_1, {0x416dbf28, [], SA_RESTART|SA_SIGINFO|0x4000000}, >> NULL, 8) = 0 >>> rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 >>> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = >> 0 >>> brk(0) = 0x1c5000 >>> brk(0x1e6000) = 0x1e6000 >>> open("/proc/self/auxv", O_RDONLY) = 3 >>> read(3, "\20\0\0\0\227\1\0\0", 8) = 8 >>> close(3) = 0 >>> sched_getparam(1235, { 0 }) = 0 >>> sched_getscheduler(1235) = 0 (SCHED_OTHER) >>> clock_getres(CLOCK_MONOTONIC, {0, 1}) = 0 >>> sched_get_priority_min(SCHED_OTHER) = 0 >>> sched_get_priority_max(SCHED_OTHER) = 0 >>> sched_get_priority_max(SCHED_OTHER) = 0 >>> gettimeofday({1315537291, 101290}, NULL) = 0 >>> --- SIGSEGV (Segmentation fault) @ 0 (0) --- >>> +++ killed by SIGSEGV +++ >>> Segmentation fault >>> >>> >>> It should have continued with: >>> >>> >>> open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No >> such file or directory) >>> open("/usr/share/locale/locale.alias", O_RDONLY|O_LARGEFILE) = -1 >> ENOENT (No such file or directory) >>> clock_gettime(CLOCK_MONOTONIC, {645, 655570927}) = 0 >>> futex(0x417d20a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0 >>> uname({sys="Linux", node="192.168.1.14", ...}) = 0 >>> socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 >>> connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 >> ENOENT (No such file or directory) >>> close(3) = 0 >>> socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 >>> connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 >> ENOENT (No such file or directory) >>> close(3) = 0 >>> open("/etc/nsswitch.conf", O_RDONLY) = 3 >>> fstat64(3, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0 >>> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40001000 >>> read(3, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465 >>> read(3, "", 4096) = 0 >>> close(3) = 0 >>> munmap(0x40001000, 4096) = 0 >>> open("/etc/ld.so.cache", O_RDONLY) = 3 >>> fstat64(3, {st_mode=S_IFREG|0644, st_size=5103, ...}) = 0 >>> mmap2(NULL, 5103, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40001000 >>> close(3) = 0 >>> open("/lib/libnss_compat.so.2", O_RDONLY) = 3 >>> read(3, >> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0T\r\0\0004\0\0\0"..., 512) = >> 512 >>> fstat64(3, {st_mode=S_IFREG|0755, st_size=26368, ...}) = 0 >>> mmap2(NULL, 57952, PROT_READ|PROT_EXEC, >> MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40009000 >>> mprotect(0x4000f000, 28672, PROT_NONE) = 0 >>> mmap2(0x40016000, 8192, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0x40016000 >>> close(3) >>> ..... >>> >>> I think the gettimeofday() before the crash is the end of the loading process. >>> None of the other binaries on the system are doing this - even demos from >>> qt4-embedded-demos. The only salient feature of this particular binary is >>> its large resource section, weighing it in at 1.4 MB. >>> >>> I'm rebuilding now with eglibc 2.13 and gcc 4.6. Will report the results. >>> >>> Regards, >>> James Limbouris > > Hi Mark, > > The host is a 32 bit only i686, and the target is an armv5te. There are no prelinker > errors in the log, and I get the same results with gcc 4.6 and eglibc 2.13. > > I've also tried installing prelink on the target, but it seems broken: > > root@192:~# opkg install prelink > Installing prelink (1.0+git1+964f6eba613bf1c791a2a0b858cd044f05e2f151-r6) to root... > Downloading http://192.168.1.11/oe-repo/armv5te/prelink_1.0+git1+964f6eba613bf1c791a2a0b858cd044f05e2f151-r6_armv5te.ipk. > Installing elfutils (0.148-r3) to root... > Downloading http://192.168.1.11/oe-repo/armv5te/elfutils_0.148-r3_armv5te.ipk. > Configuring elfutils. > Configuring prelink. > [ 1680.130000] Alignment trap: prelink-rtld (1410) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-objdump: Recorded 6 dependencies, now seeing -1 > > [ 1680.210000] Alignment trap: prelink-rtld (1411) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/sbin/prelink: Recorded 4 dependencies, now seeing -1 > > [ 1680.280000] Alignment trap: prelink-rtld (1412) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/execstack: Recorded 4 dependencies, now seeing -1 > > [ 1680.360000] Alignment trap: prelink-rtld (1413) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-strings: Recorded 4 dependencies, now seeing -1 > > [ 1680.430000] Alignment trap: prelink-rtld (1414) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-elflint: Recorded 5 dependencies, now seeing -1 > > [ 1680.510000] Alignment trap: prelink-rtld (1415) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-findtextrel: Recorded 8 dependencies, now seeing -1 > > [ 1680.580000] Alignment trap: prelink-rtld (1416) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-elfcmp: Recorded 5 dependencies, now seeing -1 > > [ 1680.660000] Alignment trap: prelink-rtld (1417) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-ranlib: Recorded 4 dependencies, now seeing -1 > > [ 1680.730000] Alignment trap: prelink-rtld (1418) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-ar: Recorded 4 dependencies, now seeing -1 > > [ 1680.810000] Alignment trap: prelink-rtld (1419) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/eu-unstrip: Recorded 8 dependencies, now seeing -1 > > [ 1680.890000] Alignment trap: prelink-rtld (1420) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /usr/bin/rica5: Recorded 27 dependencies, now seeing -1 > > > /usr/bin/rica5 above is the binary that segfaults when prelinked on the host. In the above, I first reinstalled it from an > opkg, so that it would be unprelinked, hence the prelinking attempt above. > > > root@192:~# prelink -a > [ 1768.720000] Alignment trap: prelink-rtld (1422) PC=0x45891990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > prelink: /sbin/halt.sysvinit: Dependency tracing failed > > .... the same message and alignment trap are printed for 115 other binaries. > > Regards, > James Limbouris > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-12 14:50 ` Mark Hatle @ 2011-09-13 2:58 ` James Limbouris 2011-09-13 9:16 ` Phil Blundell 0 siblings, 1 reply; 10+ messages in thread From: James Limbouris @ 2011-09-13 2:58 UTC (permalink / raw) To: Patches and discussions about the oe-core layer > -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Mark Hatle > Sent: Monday, 12 September 2011 10:50 PM > To: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Problem with new image-prelink > > Once the Linux Foundation servers come back on-line, I'll file a bug in the > bugzilla.yoctoproject.org bug tracker. > > Hopefully this is something fairly simple, and fixing the target prelink-rtld > will also resolve the failed prelinking for the QT binary. > > I hope to get to investigating this tomorrow. If you have time, you should be > able to capture a core, or use gdb on the target and figure out where the bad > alignment trap is occurring. > > The failure is in the "prelink-rtld" binary. Most likely when it's being run using: > > RTLD_WARN= RTLD_TRACE_PRELINKING=1 prelink-rtld <binary> > > That should fail with the same unaligned access.. > > Once that works and no longer fails.... it should produce the same output as if > you ran: > > LD_WARN= LD_TRACE_LOADED_OBJECTS=1 LD_TRACE_PRELINKING=1 > LD_BIND_NOW=1 > /lib/ld-linux.so.3 <binary> > > (/lib/ld-linux.so.3 is from memory so I may be wrong..) Any deviation between > the two could point to an alternative cause to the QT failure as well. > > --Mark Thanks Mark. Here is a backtrace of the alignment trap, after enabling SIGBUS when faulting: root@192:~# gdb prelink <...> Reading symbols from /usr/sbin/prelink...Reading symbols from /usr/sbin/.debug/prelink...done. done. (gdb) set follow-fork-mode child (gdb) run -a Starting program: /usr/sbin/prelink -a [New process 1712] process 1712 is executing new program: /usr/sbin/prelink-rtld [ 2777.370000] Alignment trap: prelink-rtld (1712) PC=0x410f9990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 Program received signal SIGBUS, Bus error. [Switching to process 1712] 0x410f9990 in __ctype_b_loc () at ../include/ctype.h:30 30 *tablep = (const uint16_t *) _NL_CURRENT (LC_CTYPE, _NL_CTYPE_CLASS) + 128; (gdb) bt #0 0x410f9990 in __ctype_b_loc () at ../include/ctype.h:30 #1 __option_is_short (__opt=<optimized out>) at argp.h:579 #2 convert_options (argp=0x0, parent=0x0, parent_index=121872, group=<optimized out>, cvt=0xbebd1b98) at argp-parse.c:335 #3 0x410f9938 in convert_options (argp=0x4114f210, parent=0x0, parent_index=3200064088, group=<optimized out>, cvt=0xbebd1b98) at argp-parse.c:406 #4 0x410f9c80 in parser_convert (flags=0, argp=0xbebd1a58, parser=0xbebd1ae0) at argp-parse.c:435 #5 parser_init (input=0x0, flags=0, argv=0xbebd1e74, argc=3, argp=<optimized out>, parser=0xbebd1ae0) at argp-parse.c:515 #6 __argp_parse (argp=<optimized out>, argc=3, argv=0xbebd1e74, flags=0, end_index=0xbebd1cfc, input=0x0) at argp-parse.c:915 #7 0x00009784 in main (argc=1090670408, argv=0x0) at rtld.c:895 (gdb) I've never used argp before, but I couldn't find anything wrong with rtld.c ... Regards, James ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-13 2:58 ` James Limbouris @ 2011-09-13 9:16 ` Phil Blundell 2011-09-14 0:52 ` Mark Hatle 0 siblings, 1 reply; 10+ messages in thread From: Phil Blundell @ 2011-09-13 9:16 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Tue, 2011-09-13 at 02:58 +0000, James Limbouris wrote: > root@192:~# gdb prelink > <...> > Reading symbols from /usr/sbin/prelink...Reading symbols from /usr/sbin/.debug/prelink...done. > done. > (gdb) set follow-fork-mode child > (gdb) run -a > Starting program: /usr/sbin/prelink -a > [New process 1712] > process 1712 is executing new program: /usr/sbin/prelink-rtld > [ 2777.370000] Alignment trap: prelink-rtld (1712) PC=0x410f9990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 > > Program received signal SIGBUS, Bus error. > [Switching to process 1712] > 0x410f9990 in __ctype_b_loc () at ../include/ctype.h:30 > 30 *tablep = (const uint16_t *) _NL_CURRENT (LC_CTYPE, _NL_CTYPE_CLASS) + 128; Just in case it's not obvious, the fact that this address is unaligned is the least of your worries. Even if alignment didn't matter, you would just get a segfault instead since 0x25 is never going to be a valid pointer. I guess you need to investigate where the value in r2 is coming from and figure out why it has this bogus value. p. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-13 9:16 ` Phil Blundell @ 2011-09-14 0:52 ` Mark Hatle 2011-09-14 1:33 ` James Limbouris 0 siblings, 1 reply; 10+ messages in thread From: Mark Hatle @ 2011-09-14 0:52 UTC (permalink / raw) To: openembedded-core Please try the new version of the prelinker. I just sent a pull request for it, but there was a missing typecast on a printf. This was causing problems on various systems, and likely could be causing the issue that you observed on ARM as well. I did build the latest version for the ARM target, and successfully ran it there under QEMU. --Mark On 9/13/11 4:16 AM, Phil Blundell wrote: > On Tue, 2011-09-13 at 02:58 +0000, James Limbouris wrote: >> root@192:~# gdb prelink >> <...> >> Reading symbols from /usr/sbin/prelink...Reading symbols from /usr/sbin/.debug/prelink...done. >> done. >> (gdb) set follow-fork-mode child >> (gdb) run -a >> Starting program: /usr/sbin/prelink -a >> [New process 1712] >> process 1712 is executing new program: /usr/sbin/prelink-rtld >> [ 2777.370000] Alignment trap: prelink-rtld (1712) PC=0x410f9990 Instr=0xe5922024 Address=0x00000025 FSR 0x001 >> >> Program received signal SIGBUS, Bus error. >> [Switching to process 1712] >> 0x410f9990 in __ctype_b_loc () at ../include/ctype.h:30 >> 30 *tablep = (const uint16_t *) _NL_CURRENT (LC_CTYPE, _NL_CTYPE_CLASS) + 128; > > Just in case it's not obvious, the fact that this address is unaligned > is the least of your worries. Even if alignment didn't matter, you > would just get a segfault instead since 0x25 is never going to be a > valid pointer. > > I guess you need to investigate where the value in r2 is coming from and > figure out why it has this bogus value. > > p. > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-14 0:52 ` Mark Hatle @ 2011-09-14 1:33 ` James Limbouris 2011-09-14 14:30 ` Mark Hatle 0 siblings, 1 reply; 10+ messages in thread From: James Limbouris @ 2011-09-14 1:33 UTC (permalink / raw) To: Patches and discussions about the oe-core layer > -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Mark Hatle > Sent: Wednesday, 14 September 2011 8:52 AM > To: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Problem with new image-prelink > > Please try the new version of the prelinker. I just sent a pull request for it, > but there was a missing typecast on a printf. This was causing problems on > various systems, and likely could be causing the issue that you observed on > ARM > as well. > > I did build the latest version for the ARM target, and successfully ran it there > under QEMU. > > --Mark Thanks Mark - all working, on host and target. James ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-14 1:33 ` James Limbouris @ 2011-09-14 14:30 ` Mark Hatle 2011-09-15 1:01 ` James Limbouris 0 siblings, 1 reply; 10+ messages in thread From: Mark Hatle @ 2011-09-14 14:30 UTC (permalink / raw) To: openembedded-core On 9/13/11 8:33 PM, James Limbouris wrote: >> -----Original Message----- >> From: openembedded-core-bounces@lists.openembedded.org >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of >> Mark Hatle >> Sent: Wednesday, 14 September 2011 8:52 AM >> To: openembedded-core@lists.openembedded.org >> Subject: Re: [OE-core] Problem with new image-prelink >> >> Please try the new version of the prelinker. I just sent a pull request for it, >> but there was a missing typecast on a printf. This was causing problems on >> various systems, and likely could be causing the issue that you observed on >> ARM >> as well. >> >> I did build the latest version for the ARM target, and successfully ran it there >> under QEMU. >> >> --Mark > > Thanks Mark - all working, on host and target. Does this also resolve the initial issue you found, QT failing to work after prelinking? If not, I'd like to open a new defect on it and see if we can figure out the cause still... --Mark > James > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Problem with new image-prelink 2011-09-14 14:30 ` Mark Hatle @ 2011-09-15 1:01 ` James Limbouris 0 siblings, 0 replies; 10+ messages in thread From: James Limbouris @ 2011-09-15 1:01 UTC (permalink / raw) To: Patches and discussions about the oe-core layer > -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of > Mark Hatle > Sent: Wednesday, 14 September 2011 10:30 PM > To: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Problem with new image-prelink > > On 9/13/11 8:33 PM, James Limbouris wrote: > >> -----Original Message----- > >> From: openembedded-core-bounces@lists.openembedded.org > >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf > Of > >> Mark Hatle > >> Sent: Wednesday, 14 September 2011 8:52 AM > >> To: openembedded-core@lists.openembedded.org > >> Subject: Re: [OE-core] Problem with new image-prelink > >> > >> Please try the new version of the prelinker. I just sent a pull request for it, > >> but there was a missing typecast on a printf. This was causing problems on > >> various systems, and likely could be causing the issue that you observed on > >> ARM > >> as well. > >> > >> I did build the latest version for the ARM target, and successfully ran it there > >> under QEMU. > >> > >> --Mark > > > > Thanks Mark - all working, on host and target. > > Does this also resolve the initial issue you found, QT failing to work after > prelinking? > > If not, I'd like to open a new defect on it and see if we can figure out the > cause still... > > --Mark Yes, the Qt app is running as well. Thanks, James ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-15 1:06 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-09 3:34 Problem with new image-prelink James Limbouris 2011-09-09 15:57 ` Mark Hatle 2011-09-12 1:39 ` James Limbouris 2011-09-12 14:50 ` Mark Hatle 2011-09-13 2:58 ` James Limbouris 2011-09-13 9:16 ` Phil Blundell 2011-09-14 0:52 ` Mark Hatle 2011-09-14 1:33 ` James Limbouris 2011-09-14 14:30 ` Mark Hatle 2011-09-15 1:01 ` James Limbouris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox