(I couldn't tell if this belonged here or in the BIOS or Linux forum.)
Hi,
I use c6run to create an ARM+DSP application on my OMAP3530. In tracking down a buffer problem I ran Valgrind 3.6.0 and it found quite a few instances of uninitialized variables coming from DSPLink. In most cases, it's due to a CMD_Args struct pointer being used as an in parameter without being memset first. I haven't tracked things down to see whether uninitialized struct members are actually being used, but the reported uninitialized reads inside _POOL_xltBuf has me slightly worried. Initializing the local variables pointed out by Valgrind silences the warnings, but as this could potentially mask away actual issues I'm a bit reluctant to do that.
For reference I called valgrind with --tool=memcheck --leak-check=no --track-origins=yes.
C6Run uses DSPLink 1.65.00.02.
==1205== Use of uninitialised value of size 4 ==1205== at 0x8AE48: _SYNC_USR_createCS (_sync_usr.c:401) ==1205== by 0x86B33: PROC_setup (proc.c:282) ==1205== by 0x8BD37: C6RUN_IPC_create (C6Run_ipc.c:231) ==1205== by 0x7C62F: C6RUN_init (C6Run.c:185) ==1205== by 0x7B68B: [.gpp_stub.c] [snip] ==1205== Uninitialised value was created by a stack allocation ==1205== at 0x8AD8C: _SYNC_USR_createCS (_sync_usr.c:356) ==1205== Conditional jump or move depends on uninitialised value(s) ==1205== at 0x85884: _POOL_xltBuf (_pool.c:186) ==1205== by 0x82243: DRV_Invoke (drv_api.c:617) ==1205== by 0x84C4F: MSGQ_alloc (msgq.c:530) ==1205== by 0x7D63F: CONTROL_IPC_init (control_ipc.c:186) ==1205== by 0x8BE03: C6RUN_IPC_create (C6Run_ipc.c:316) ==1205== by 0x7C62F: C6RUN_init (C6Run.c:185) ==1205== by 0x7B68B: [.gpp_stub.c] [snip] ==1205== Uninitialised value was created by a stack allocation ==1205== at 0x85C14: POOL_open (pool.c:122)
Thanks,
Orjan