|
From: Yeshurun, M. <mei...@in...> - 2006-05-24 09:46:01
|
Hi, The platform is SuSE64 on EM64T, but I think it happens on all our Linux platforms (e.g. Red Hat). The executable is 32-bit. BTW, I just noticed the executable is stripped.=20 Thanks for the quick response! Meir --16032:1:debuglog DebugLog system started by Stage 1, level 2 logging requested --16032:1:launcher no tool requested, defaulting to 'memcheck' --16032:1:launcher selected platform 'x86-linux' --16032:1:launcher launching /p/dt/sde/tools/x86-64_linux26/valgrind-3.1.1/lib/valgrind/x86-linux/mem check --16032:1:debuglog DebugLog system started by Stage 2 (main), level 2 logging requested --16032:1:main Welcome to Valgrind version 3.1.1 debug logging --16032:1:main Checking current stack is plausible --16032:1:main Checking initial stack was noted --16032:1:main Starting the address space manager --16032:2:aspacem sp_at_startup =3D 0x00FFFFBF60 (supplied) --16032:2:aspacem minAddr =3D 0x0004000000 (computed) --16032:2:aspacem maxAddr =3D 0x00FFFFAFFF (computed) --16032:2:aspacem cStart =3D 0x0004000000 (computed) --16032:2:aspacem vStart =3D 0x0001FFE000 (computed) --16032:2:aspacem suggested_clstack_top =3D 0x00FEFFBFFF (computed) --16032:2:aspacem <<< SHOW_SEGMENTS: Initial layout (5 segments, 0 segnames) --16032:2:aspacem 0: RSVN 0000000000-0001FFDFFF 31m ----- SmFixed --16032:2:aspacem 1: RSVN 0001FFE000-0001FFEFFF 4096 ----- SmFixed --16032:2:aspacem 2: RSVN 0001FFF000-0003FFFFFF 32m ----- SmFixed --16032:2:aspacem 3: 0004000000-00FFFFAFFF 4031m --16032:2:aspacem 4: RSVN 00FFFFB000-00FFFFFFFF 20480 ----- SmFixed --16032:2:aspacem >>> --16032:2:aspacem Reading /proc/self/maps --16032:2:aspacem <<< SHOW_SEGMENTS: With contents of /proc/self/maps (11 segments, 1 segnames) --16032:2:aspacem ( 0) /nfs/iil/dt/sde04/tools/x86-64_linux26/valgrind-3.1.1/lib/valgrind/x86-l inux/memcheck --16032:2:aspacem 0: RSVN 0000000000-0001FFDFFF 31m ----- SmFixed --16032:2:aspacem 1: RSVN 0001FFE000-0001FFEFFF 4096 ----- SmFixed --16032:2:aspacem 2: RSVN 0001FFF000-0003FFFFFF 32m ----- SmFixed --16032:2:aspacem 3: 0004000000-006FFFFFFF 1728m --16032:2:aspacem 4: FILE 0070000000-0070141FFF 1318912 r-x-- d=3D0x0DE i=3D2742579 o=3D0 (0) --16032:2:aspacem 5: FILE 0070142000-0070142FFF 4096 rwx-- d=3D0x0DE i=3D2742579 o=3D1318912 (0) --16032:2:aspacem 6: ANON 0070143000-00707E7FFF 6967296 rwx-- --16032:2:aspacem 7: 00707E8000-00FFFFAFFF 2296m --16032:2:aspacem 8: ANON 00FFFFB000-00FFFFDFFF 12288 rw--- --16032:2:aspacem 9: ANON 00FFFFE000-00FFFFEFFF 4096 ----- --16032:2:aspacem 10: RSVN 00FFFFF000-00FFFFFFFF 4096 ----- SmFixed --16032:2:aspacem >>> --16032:1:main Address space manager is running --16032:1:main Starting the dynamic memory manager --16032:1:mallocfr newSuperblock at 0x4000000 (pszB 1048560) owner VALGRIND/tool --16032:1:main Dynamic memory manager is running --16032:1:main Getting stage1's name --16032:1:main Get hardware capabilities ... --16032:1:main ... arch =3D X86, subarch =3D x86-sse2 --16032:1:main Split up command line --16032:1:main Preprocess command line opts --16032:1:main Loading client valgrind: <binary executable pathname>: VG_(strerror): unknown error -----Original Message----- From: Julian Seward [mailto:js...@ac...]=20 Sent: Wednesday, May 24, 2006 12:30 PM To: val...@li... Cc: Yeshurun, Meir Subject: Re: [Valgrind-users] Valgrind crashes on start-up Try again with -d -d -v and send the results. What platform (cpu, os) are you running on? J On Wednesday 24 May 2006 10:17, Yeshurun, Meir wrote: > Hi, > > On some applications, Valgrind 3.1.1 (as well as 3.1.0) crashes > immediately at startup with this message: > > VG_(strerror): unknown error > (This is all I get even with -v) > > What should I do? > > Thanks! > > Meir |
|
From: Yeshurun, M. <mei...@in...> - 2006-05-24 10:11:30
|
Pardon my ignorance, but I don't know how to use that file. Please help.
Thanks,
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Wednesday, May 24, 2006 1:01 PM
To: val...@li...
Subject: Re: [Valgrind-users] Valgrind crashes on start-up
In message
<D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> --16032:1:main Loading client
>
> valgrind: <binary executable pathname>: VG_(strerror): unknown error
Try the attached patch - it should make the error message make
a bit more sense...
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2006-05-24 10:23:58
|
In message <D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> Pardon my ignorance, but I don't know how to use that file. Please help.
In the top directory of the source tree do this:
patch -p0 -N < valgrind-error.patch
then rebuild valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yeshurun, M. <mei...@in...> - 2006-05-24 10:30:44
|
Sorry, I get still get exactly the same error message.
Thanks
Meir
-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Tom
Hughes
Sent: Wednesday, May 24, 2006 1:24 PM
To: Yeshurun, Meir
Cc: val...@li...
Subject: Re: [Valgrind-users] Valgrind crashes on start-up
In message
<D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> Pardon my ignorance, but I don't know how to use that file. Please
help.
In the top directory of the source tree do this:
patch -p0 -N < valgrind-error.patch
then rebuild valgrind.
Tom
--=20
Tom Hughes (to...@co...)
http://www.compton.nu/
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications
in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D107521&bid=3D248729&dat=3D=
121642
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Yeshurun, M. <mei...@in...> - 2006-05-24 10:39:44
|
Here is the output of 'size':
text data bss dec hex filename
40307616 43664 31154516 71505796 4431784=20
I'll try to follow your instructions and get back to you with the
results.
Thanks,
Meir
Original Message-----
From: Julian Seward [mailto:js...@ac...]=20
Sent: Wednesday, May 24, 2006 1:30 PM
To: val...@li...
Cc: Tom Hughes; Yeshurun, Meir
Subject: Re: [Valgrind-users] Valgrind crashes on start-up
> Try the attached patch - it should make the error message make
> a bit more sense...
The printf is certainly wrong (r5925 fixes it I see), but I don't
think that helps here. The problem is the switch in VG_(strerror)
doesn't handle whatever error code showed up.
Meir: look at the end of coregrind/m_syscall.c, function=20
VG_(strerror). For the default case you could perhaps add
VG_(printf)("XXX error code is %d\n", (Int)errnum);
rebuild, rerun, get the error code (presumably a small int
in the range 0 .. 200 ish) and look it up in one of these:
/usr/include/asm-generic/errno-base.h
/usr/include/asm-generic/errno.h
/usr/include/linux/errno.h
/usr/include/bits/errno.h
Also: does this executable have extremely large (100+ MB) text,
data or bss segments? What does 'size <exename>' say? =20
Very large segments is the only reason I can think of right now
why V's ELF loader would fail.
J
|
|
From: Yeshurun, M. <mei...@in...> - 2006-05-24 10:46:43
|
Does this make sense?
#define EOVERFLOW 75 /* Value too large for defined data type
*/
Thanks,
Meir
-----Original Message-----
From: Julian Seward [mailto:js...@ac...]=20
Sent: Wednesday, May 24, 2006 1:30 PM
To: val...@li...
Cc: Tom Hughes; Yeshurun, Meir
Subject: Re: [Valgrind-users] Valgrind crashes on start-up
> Try the attached patch - it should make the error message make
> a bit more sense...
The printf is certainly wrong (r5925 fixes it I see), but I don't
think that helps here. The problem is the switch in VG_(strerror)
doesn't handle whatever error code showed up.
Meir: look at the end of coregrind/m_syscall.c, function=20
VG_(strerror). For the default case you could perhaps add
VG_(printf)("XXX error code is %d\n", (Int)errnum);
rebuild, rerun, get the error code (presumably a small int
in the range 0 .. 200 ish) and look it up in one of these:
/usr/include/asm-generic/errno-base.h
/usr/include/asm-generic/errno.h
/usr/include/linux/errno.h
/usr/include/bits/errno.h
Also: does this executable have extremely large (100+ MB) text,
data or bss segments? What does 'size <exename>' say? =20
Very large segments is the only reason I can think of right now
why V's ELF loader would fail.
J
|
|
From: Julian S. <js...@ac...> - 2006-05-24 11:29:55
|
> #define EOVERFLOW 75 /* Value too large for defined data type > text data bss dec hex filename > 40307616 43664 31154516 71505796 4431784 There's something funny about all this. As far as I can tell from a bit of googling, EOVERFLOW means something along the lines of "the file offset cannot be represented in a 32-bit int." Our ELF loader does do reading of the executable at various offsets so that kinda makes sense. However, according to your numbers you have 40M text, minimal data, 31M bss sections, together which gets us nowhere near the limit for a 32-bit int. How big is the executable file itself, about 72M ? Does the program require huge amounts of memory when running? Uh .. without being able to reproduce this, which I presume is impossible, I'm mystified. Tom, any ideas? J |
|
From: Tom H. <to...@co...> - 2006-05-24 11:45:06
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> #define EOVERFLOW 75 /* Value too large for defined data type
>
>> text data bss dec hex filename
>> 40307616 43664 31154516 71505796 4431784
>
> There's something funny about all this. As far as I can tell from a
> bit of googling, EOVERFLOW means something along the lines of "the
> file offset cannot be represented in a 32-bit int." Our ELF loader
> does do reading of the executable at various offsets so that kinda
> makes sense.
I'm similarly confused - there is only place where the kernel code
for mmap appears to return EOVERFLOW and that seems to be when the
offset + length overflows.
> Tom, any ideas?
An strace of valgrind might be useful - just add "strace -o
strace.out" to the start of your normal command line and send
use the strace.out file.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-05-24 12:24:16
|
> I'm similarly confused - there is only place where the kernel code > for mmap appears to return EOVERFLOW and that seems to be when the > offset + length overflows. Wow, what service. Tom searched the entire kernel for you :) Meir, the best I can suggest is you snoop around m_ume.c (the ELF loader) and stick in enough VG_(printf)s to figure out whereabouts the error condition is appears. That would help. J |
|
From: Tom H. <to...@co...> - 2006-05-24 12:45:16
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> I'm similarly confused - there is only place where the kernel code
>> for mmap appears to return EOVERFLOW and that seems to be when the
>> offset + length overflows.
>
> Wow, what service. Tom searched the entire kernel for you :)
Well mm/mmap.c anyway ;-)
> Meir, the best I can suggest is you snoop around m_ume.c (the
> ELF loader) and stick in enough VG_(printf)s to figure out
> whereabouts the error condition is appears. That would help.
To be honest I'm not even sure it is coming from mmap as m_ume.c
uses check_mmap after each mmap I think, and that would abort
straight away and give details.
That's why I think an strace might be more helpful.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-05-24 12:48:31
|
> To be honest I'm not even sure it is coming from mmap as m_ume.c > uses check_mmap after each mmap I think, and that would abort > straight away and give details. > > That's why I think an strace might be more helpful. Ah yes. Good point. J |
|
From: Julian S. <js...@ac...> - 2006-05-24 12:50:09
|
> That's why I think an strace might be more helpful. Duh .. what I meant to add was: there are also some VG_(pread)s in there -- maybe it's to do with them? J |
|
From: Yeshurun, M. <mei...@in...> - 2006-05-24 18:21:08
|
Thanks indeed to the both of you for the incredible service!! :-) =20 I will continue to investigate the problem as you suggested. The good news is that this problem doesn't occur with versions <=3D = 3.0.1 (including 2.4.1), only with >=3D 3.1.0. So we are still able to use Valgrind after all (should have tried this sooner...sorry). Perhaps this will also give you a clue as to what the problem is. Thanks again, Meir -----Original Message----- From: Julian Seward [mailto:js...@ac...]=20 Sent: Wednesday, May 24, 2006 3:24 PM To: val...@li... Cc: Tom Hughes; Yeshurun, Meir Subject: Re: [Valgrind-users] Valgrind crashes on start-up > I'm similarly confused - there is only place where the kernel code > for mmap appears to return EOVERFLOW and that seems to be when the > offset + length overflows. Wow, what service. Tom searched the entire kernel for you :) Meir, the best I can suggest is you snoop around m_ume.c (the ELF loader) and stick in enough VG_(printf)s to figure out=20 whereabouts the error condition is appears. That would help. J |
|
From: Dirk M. <dmu...@su...> - 2006-05-26 11:06:00
|
On Wednesday 24 May 2006 20:19, you wrote: > I will continue to investigate the problem as you suggested. Does this happen with any application, or just with a specific one? if so, is it part of SLES? If so, you might go to bugzilla.novell.com and file a bugreport (assign it to me). Dirk |
|
From: Tom H. <to...@co...> - 2006-05-24 10:00:52
Attachments:
valgrind-error.patch
|
In message <D01...@ha...>
Meir Yeshurun <mei...@in...> wrote:
> --16032:1:main Loading client
>
> valgrind: <binary executable pathname>: VG_(strerror): unknown error
Try the attached patch - it should make the error message make
a bit more sense...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-05-24 10:30:28
|
> Try the attached patch - it should make the error message make
> a bit more sense...
The printf is certainly wrong (r5925 fixes it I see), but I don't
think that helps here. The problem is the switch in VG_(strerror)
doesn't handle whatever error code showed up.
Meir: look at the end of coregrind/m_syscall.c, function
VG_(strerror). For the default case you could perhaps add
VG_(printf)("XXX error code is %d\n", (Int)errnum);
rebuild, rerun, get the error code (presumably a small int
in the range 0 .. 200 ish) and look it up in one of these:
/usr/include/asm-generic/errno-base.h
/usr/include/asm-generic/errno.h
/usr/include/linux/errno.h
/usr/include/bits/errno.h
Also: does this executable have extremely large (100+ MB) text,
data or bss segments? What does 'size <exename>' say?
Very large segments is the only reason I can think of right now
why V's ELF loader would fail.
J
|