|
From: John C. <joh...@ta...> - 2004-03-15 05:36:02
|
I'm getting the message stated in the subject line from
--gen-suppression=yes.
Is this a known bug? Lack of debug symbols? (there is
some assembler involved) Or perhaps user error?
---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
{
<insert a suppression name here>
Memcheck:Param
sigaction(act)
???:??? # unknown, suppression will not work, sorry)
???:??? # unknown, suppression will not work, sorry)
???:??? # unknown, suppression will not work, sorry)
}
The version is CVS latest (I need the static libs stuff) as at Mon Mar 15
05:34:50 UTC 2004
Thanks,
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : joh...@ta...
New Zealand
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-16 17:59:15
|
On Mon, 15 Mar 2004, John Carter wrote:
> I'm getting the message stated in the subject line from
> --gen-suppression=yes.
>
> Is this a known bug? Lack of debug symbols? (there is
> some assembler involved) Or perhaps user error?
>
> ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
> {
> <insert a suppression name here>
> Memcheck:Param
> sigaction(act)
> ???:??? # unknown, suppression will not work, sorry)
> ???:??? # unknown, suppression will not work, sorry)
> ???:??? # unknown, suppression will not work, sorry)
> }
This means Valgrind can't find any debug info or symbol table info. Is
the binary stripped? What does the corresponding error message look like?
N
|
|
From: John C. <joh...@ta...> - 2004-03-16 23:52:17
|
On Tue, 16 Mar 2004, Nicholas Nethercote wrote:
> On Mon, 15 Mar 2004, John Carter wrote:
>
> > I'm getting the message stated in the subject line from
> > --gen-suppression=yes.
> >
> > Is this a known bug? Lack of debug symbols? (there is
> > some assembler involved) Or perhaps user error?
> >
> > ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- y
> > {
> > <insert a suppression name here>
> > Memcheck:Param
> > sigaction(act)
> > ???:??? # unknown, suppression will not work, sorry)
> > ???:??? # unknown, suppression will not work, sorry)
> > ???:??? # unknown, suppression will not work, sorry)
> > }
>
> This means Valgrind can't find any debug info or symbol table info. Is
> the binary stripped? What does the corresponding error message look like?
I suspect the code concerned is a bit of assembler in eCos (Embedded
Configurable Operating System) thus the debug info / symbol table
might be rather strange. I would be content to suppress just that
exact address, no matter what the call stack looked like.
The error message result looks like....
==3150== Syscall param sigaction(act) contains uninitialised or unaddressable byte(s)
==3150== at 0x1009D33: ???
==3150== by 0x1008224: ???
==3150== by 0x4FFFEBBB: ???
==3150== Address 0x4FFFEA78 is on thread 1's stack
==3150==
the debugger backtrace looks like....
#0 0x01009d33 in cyg_hal_sys_sigaction ()
at /home/johnc/work/mapped/ecos/synth/rom/install/include/cyg/libc/stdio/stream.inl:91
#1 0x010099be in synth_hardware_init ()
at /opt/ecos/ecos-2.0/packages/hal/synth/arch/v2_0/src/synth_intr.c:1283
#2 0x01008225 in _linux_entry ()
at /opt/ecos/ecos-2.0/packages/hal/synth/arch/v2_0/src/synth_entry.c:143
#3 0x4fffebbc in ?? ()
The #0 frame is an assembler chunk that just invokes the sigaction syscall.
.globl cyg_hal_sys_sigaction;
cyg_hal_sys_sigaction:
push %ebx;
mov 8(%esp), %ebx;
mov 12(%esp), %ecx;
mov 16(%esp), %edx;
lea 67, %eax;
int $0x80;
pop %ebx;
ret;
.type cyg_hal_sys_sigaction,@function ; .size cyg_hal_sys_sigaction,1b - cyg_hal_sys_sigaction
Curiously enough I have checked, every field passed in is
initialised and is on the stack.
This is using valgrind cvs latest Tue Mar 16 23:50:30 UTC 2004
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : joh...@ta...
New Zealand
The universe is absolutely plastered with the dashed lines exactly one
space long.
|
|
From: Nicholas N. <nj...@ca...> - 2004-03-17 10:49:43
|
On Wed, 17 Mar 2004, John Carter wrote: > I suspect the code concerned is a bit of assembler in eCos (Embedded > Configurable Operating System) thus the debug info / symbol table > might be rather strange. I would be content to suppress just that > exact address, no matter what the call stack looked like. Unfortunately Valgrind has no support for address-only suppressions. In general I would think they would not be reliable, since recompiling a program can move code around. Is it possible to compile the assembly code with debugging info, or manually insert some? (not sure if you can do that) > ==3150== Syscall param sigaction(act) contains uninitialised or unaddressablebyte(s) > > The #0 frame is an assembler chunk that just invokes the sigaction syscall. > .globl cyg_hal_sys_sigaction; > > cyg_hal_sys_sigaction: > push %ebx; > mov 8(%esp), %ebx; > mov 12(%esp), %ecx; > mov 16(%esp), %edx; > lea 67, %eax; > int $0x80; > pop %ebx; > ret; > .type cyg_hal_sys_sigaction,@function ; .size cyg_hal_sys_sigaction,1b - cyg_hal_sys_sigaction > > Curiously enough I have checked, every field passed in is > initialised and is on the stack. I think the "sigaction(act)" error means that the pointed-to struct is uninitialised/unaddressable, rather than the pointer itself. N |