|
From: Bram De W. <bde...@gm...> - 2009-08-12 13:22:23
|
I compiled valgrind 3.4.1 using ./configure --build=powerpc-linux-uclibc
--host=ppc-linux-uclibc --enable-tls=no --prefix=/mnt/cflash/valgrind
Target is powerpc linux embedded device (debian base) with uclibc.
# ./valgrind /usr/bin/scp
valgrind: /usr/bin/scp: bad ELF magic number
valgrind: cannot execute binary file
It all seems to boil down to VG_(pread) (or more specifically VG_(lseek))
not working correctly on my system. Here is the relevant portion of strace:
open("/usr/bin/scp", O_RDONLY) = 3
stat64("/usr/bin/scp", {st_mode=S_IFREG|0755, st_size=40140, ...}) = 0
geteuid() = 0
fstat64(3, {st_mode=S_IFREG|0755, st_size=40140, ...}) = 0
lseek(3, 0, SEEK_SET) = 0
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 4096) =
4096
lseek(3, 0, SEEK_SET) = 0
read(3, "\335\335\335\335\335\335\335\335\335\335\335\335\335\335"..., 52) =
52
write(2, "valgrind: /usr/bin/scp: bad ELF "..., 45) = 45
The code does 2 calls to pread. The first one reads the correct magic number
(\177ELF), while the second reads garbish (\355\355\355\355).
Remark that all system calls return without error.
Additionally, I tried a small test C-program compiled with the same compiler
which makes direct call to pread, and it works like a charm. The same OK
result with a test program that does the same operation as valgrind (not
using the VG_() macros) : lseek, read, lseek, read. All work fine.
Any help would be greatly apreciated.
Bram.
|
|
From: Nicholas N. <n.n...@gm...> - 2009-08-12 22:33:42
|
On Wed, Aug 12, 2009 at 11:22 PM, Bram De Wachter<bde...@gm...> wrote:
>
> It all seems to boil down to VG_(pread) (or more specifically VG_(lseek))
> not working correctly on my system. Here is the relevant portion of strace:
Here is the code for VG_(pread). The comment at the top seems very relevant:
/* DDD: Note this moves (or at least, is believed to move) the file pointer
on Linux and AIX5 but doesn't on Darwin. This inconsistency should
be fixed. (In other words, why isn't the Linux/AIX5 version implemented in
terms of pread()?) */
SysRes VG_(pread) ( Int fd, void* buf, Int count, OffT offset )
{
SysRes res;
# if defined(VGO_linux) || defined(VGO_aix5)
/* Linux, AIX5 */
OffT off = VG_(lseek)( fd, offset, VKI_SEEK_SET);
if (off < 0)
return VG_(mk_SysRes_Error)( VKI_EINVAL );
res = VG_(do_syscall3)(__NR_read, fd, (UWord)buf, count );
return res;
# elif defined(VGP_amd64_darwin)
res = VG_(do_syscall4)(__NR_pread_nocancel, fd, (UWord)buf, count, offset);
return res;
# elif defined(VGP_x86_darwin)
/* ppc32-darwin is the same, but with the args inverted */
res = VG_(do_syscall5)(__NR_pread_nocancel, fd, (UWord)buf, count,
offset & 0xffffffff, offset >> 32);
return res;
# else
# error "Unknown platform"
# endif
}
I don't know why the linux/aix5 version uses VG_(lseek) then
__NR_read, it seems like it should just use __NR_pread64 directly,
similar to the Darwin versions. Can you try changing it to do that
and report back whether it fixes the problem?
Nick
|
|
From: Bram De W. <bde...@gm...> - 2009-08-13 13:55:11
|
2009/8/12 Nicholas Nethercote
> On Wed, Aug 12, 2009 at 11:22 PM, Bram De Wachter wrote:
> >
> > It all seems to boil down to VG_(pread) (or more specifically VG_(lseek))
> > not working correctly on my system. Here is the relevant portion of
> strace:
>
> Here is the code for VG_(pread). The comment at the top seems very
> relevant:
>
> I don't know why the linux/aix5 version uses VG_(lseek) then
> __NR_read, it seems like it should just use __NR_pread64 directly,
> similar to the Darwin versions. Can you try changing it to do that
> and report back whether it fixes the problem?
>
> Nick
>
Tried it first thing this morning. Without success. Still same garbish at
the second (now pread64) syscall.
But even if it worked, this would still not fix any future calls to lseek()
?
Anyway, something else is not right. Maybe this can help :
int main() {
int fd = open("/usr/bin/scp", O_RDONLY);
char buf[4096];
pread(fd, buf, 4096, 0);
pread(fd, buf, 4096, 0);
close(fd);
}
produced strace:
open("/usr/bin/scp", O_RDONLY) = 3
pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "...,
4096, 0) = 4096
pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "...,
4096, 0) = 4096
close(3) = 0
This what valgrind outputs (with the requested change) :
open("/usr/bin/scp", O_RDONLY) = 3
stat64("/usr/bin/scp", {st_mode=S_IFREG|0755, st_size=40140, ...}) = 0
geteuid() = 0
fstat64(3, {st_mode=S_IFREG|0755, st_size=40140, ...}) = 0
pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "...,
4096, 0) = 4096
pread64(3, "\335\335\335\335\335\335\335\335\335\335\335\335\335\335"...,
52, 0) = 52
write(2, "valgrind: /usr/bin/scp: bad ELF "..., 45) = 45
close(3) = 0
Except for the geteuid(), stat64() and fstat64(), there seems to be no
difference.
Thanks for any light.
Bram.
|
|
From: Nicholas N. <n.n...@gm...> - 2009-08-13 23:21:10
|
On Thu, Aug 13, 2009 at 11:54 PM, Bram De Wachter<bde...@gm...> wrote: > > Tried it first thing this morning. Without success. Still same garbish at > the second (now pread64) syscall. > But even if it worked, this would still not fix any future calls to lseek() > ? > Anyway, something else is not right. Can you please file a bug report? (http://www.valgrind.org/support/bug_reports.html) We're busy with the imminent 3.5.0 release right now, filing a bug is the best way to ensure this problem doesn't get lost. Thanks. Nick |
|
From: John R. <jr...@bi...> - 2009-08-14 13:52:03
|
> pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 4096, 0) = 4096 > pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 4096, 0) = 4096 --------------------------------------------------------------------------^^^^-------^^^^ [versus] > pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 4096, 0) = 4096 > pread64(3, "\335\335\335\335\335\335\335\335\335\335\335\335\335\335"..., 52, 0) = 52 ----------------------------------------------------------------------------^^-------^^ > Except for the geteuid(), stat64() and fstat64(), there seems to be no difference. The second call to pread64 has a third argument of 52 instead of 4096. -- |
|
From: Tom H. <to...@co...> - 2009-08-14 07:49:04
|
On 14/08/09 00:20, Nicholas Nethercote wrote: > On Thu, Aug 13, 2009 at 11:54 PM, Bram De Wachter<bde...@gm...> wrote: >> Tried it first thing this morning. Without success. Still same garbish at >> the second (now pread64) syscall. >> But even if it worked, this would still not fix any future calls to lseek() >> ? >> Anyway, something else is not right. > > Can you please file a bug report? > (http://www.valgrind.org/support/bug_reports.html) We're busy with > the imminent 3.5.0 release right now, filing a bug is the best way to > ensure this problem doesn't get lost. Thanks. To be honest I can't see how this can be anything valgrind is doing - if strace is showing the same pread call being made twice on the same file descriptor and with the same offset but with different data being returned then surely that has to be down to the kernel? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Julian S. <js...@ac...> - 2009-08-14 08:02:50
|
On Friday 14 August 2009, Tom Hughes wrote: > On 14/08/09 00:20, Nicholas Nethercote wrote: > > On Thu, Aug 13, 2009 at 11:54 PM, Bram De Wachter<bde...@gm...> wrote: > >> Tried it first thing this morning. Without success. Still same garbish > >> at the second (now pread64) syscall. > >> But even if it worked, this would still not fix any future calls to > >> lseek() ? > >> Anyway, something else is not right. > > > > Can you please file a bug report? > > (http://www.valgrind.org/support/bug_reports.html) We're busy with > > the imminent 3.5.0 release right now, filing a bug is the best way to > > ensure this problem doesn't get lost. Thanks. > > To be honest I can't see how this can be anything valgrind is doing I agree. I tried it just yesterday on standard ppc32 linux and it worked fine. J |
|
From: Bram De W. <bde...@gm...> - 2009-08-14 11:38:54
|
2009/8/14 Julian Seward <js...@ac...> > On Friday 14 August 2009, Tom Hughes wrote: > > On 14/08/09 00:20, Nicholas Nethercote wrote: > > > On Thu, Aug 13, 2009 at 11:54 PM, Bram De Wachter<bde...@gm...> > wrote: > > >> Tried it first thing this morning. Without success. Still same garbish > > >> at the second (now pread64) syscall. > > >> But even if it worked, this would still not fix any future calls to > > >> lseek() ? > > >> Anyway, something else is not right. > > > > > > Can you please file a bug report? > > > (http://www.valgrind.org/support/bug_reports.html) We're busy with > > > the imminent 3.5.0 release right now, filing a bug is the best way to > > > ensure this problem doesn't get lost. Thanks. > > > > To be honest I can't see how this can be anything valgrind is doing > > I agree. I tried it just yesterday on standard ppc32 linux and it > worked fine. > > J There must be something going wrong somewhere. Do you suggest I look at the assembly code and compare the test program with Valgrind's code, it's a long shot, and if there is anything else I can do before diving into that, please let me know. Bram. |
|
From: Tom H. <to...@co...> - 2009-08-14 14:21:30
|
On 14/08/09 14:43, John Reiser wrote: >> pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 4096, 0) = 4096 >> pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 4096, 0) = 4096 > > --------------------------------------------------------------------------^^^^-------^^^^ > > [versus] > >> pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 4096, 0) = 4096 >> pread64(3, "\335\335\335\335\335\335\335\335\335\335\335\335\335\335"..., 52, 0) = 52 > > ----------------------------------------------------------------------------^^-------^^ > > >> Except for the geteuid(), stat64() and fstat64(), there seems to be no difference. > > The second call to pread64 has a third argument of 52 instead of 4096. Which should be fine of course - it just means we're only asking for the first 52 bytes of the file instead of the first 4096 bytes. As far as I know there is no requirement for the size or offset given to pread to be page aligned or anything like that so both should work. It might of course explain why the test program is not showing the problem. I still reckon this is a kernel bug, although it may well be the change in the count that triggers it. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Bram De W. <bde...@gm...> - 2009-08-14 15:01:39
|
2009/8/14 Tom Hughes <to...@co...>
> On 14/08/09 14:43, John Reiser wrote:
>
>> pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "...,
>>> 4096, 0) = 4096
>>> pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "...,
>>> 4096, 0) = 4096
>>>
>>
>>
>> --------------------------------------------------------------------------^^^^-------^^^^
>>
>> [versus]
>>
>> pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "...,
>>> 4096, 0) = 4096
>>> pread64(3, "\335\335\335\335\335\335\335\335\335\335\335\335\335\335"...,
>>> 52, 0) = 52
>>>
>>
>>
>> ----------------------------------------------------------------------------^^-------^^
>>
>>
>> Except for the geteuid(), stat64() and fstat64(), there seems to be no
>>> difference.
>>>
>>
>> The second call to pread64 has a third argument of 52 instead of 4096.
>>
>
> Which should be fine of course - it just means we're only asking for the
> first 52 bytes of the file instead of the first 4096 bytes. As far as I know
> there is no requirement for the size or offset given to pread to be page
> aligned or anything like that so both should work.
>
> It might of course explain why the test program is not showing the problem.
>
> I still reckon this is a kernel bug, although it may well be the change in
> the count that triggers it.
>
>
Hate to break it to you, but 52 is not the answer (just for laughs, tried
with 42 as well)
as expected, all work fine in the test program.
Maybe it has to do with any of the mmap calls ? What follows is the complete
strace of the test program:
execve("./a.out", ["./a.out"], [/* 21 vars */]) = 0
mmap(NULL, 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x30005000
stat("/etc/ld.so.cache", {st_mode=S_IFREG|0755, st_size=3734, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
mmap(NULL, 3734, PROT_READ, MAP_SHARED, 3, 0) = 0x30006000
close(3) = 0
open("/usr/local/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libgcc_s.so.1", O_RDONLY) = 3
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x30007000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\030"..., 4096)
= 4096
mmap(NULL, 114688, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30015000
mmap(0x30015000, 47516, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x30015000
mmap(0x30030000, 2936, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0xb000) = 0x30030000
close(3) = 0
munmap(0x30007000, 4096) = 0
open("/usr/local/lib/libc.so.0", O_RDONLY) = -1 ENOENT (No such file or
directory)
open("/lib/libc.so.0", O_RDONLY) = 3
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x30007000
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\373"..., 4096)
= 4096
mmap(NULL, 360448, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30031000
mmap(0x30031000, 326620, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x30031000
mmap(0x30081000, 4596, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 3, 0x50000) = 0x30081000
mmap(0x30083000, 21640, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x30083000
close(3) = 0
munmap(0x30007000, 4096) = 0
munmap(0x30006000, 3734) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
open("/usr/bin/scp", O_RDONLY) = 3
pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "...,
4096, 0) = 4096
pread64(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\24\0\0\0\1\20\0 "..., 52,
0) = 52
close(3) = 0
exit(6) = ?
|