• Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 559 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DSPLink uninitialized values (reported by Valgrind)

Orjan Friberg
Expert 1385 points
Other Parts Discussed in Thread: OMAP3530

(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
  • TI__Expert 4930 points

    Orjan

    Thanks for providing your feedback on running Valgrind.

    Please find my comments below:

    1) CMD_Args structure is not memset.

         DSPLink code does not memset the union. However the code does ensure that the i/p parameters are correctly set when the structure is populated and the o/p parameters are correctly set in the kernel driver logic.

    2) 

    ==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)
    This code is not an issue. The variable in question  SYNC_USR_stateObj.csObjs [id] is initialized to NULL at the system initialization.
    At a process level the semaphore set is created once per process. For every subsequent call in the same process, it returns the created semaphore set.


    3) 
    ==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)
    
    This code is not an issue. The variable in question 'addr' is set prior to use. It is uninitialized at the time of the variable declaration which might be causing the warning.

    Though we don't run Valgrind, we run a static analysis tool called Klockwork which does point out similar issues in the code. We have resolved Klockwork reported issues in DSPLink.

    Deepali

  • in reply to Deepali Uppal
    Expert 1385 points

    Deepali,

    I don't know the code well enough to disagree with you, though I would say that (from x86 experience; ARM support in valgrind is fairly new) valgrind only gives these warnings when reading memory areas that have not yet been written.  I.e., not initializing a variable at declaration time should not cause these warnings.

    I have seen instances where valgrind gives the same warning when passing a struct by value where one struct member has not yet been written, even though that particular struct member is not being read.

    Thanks for looking into it,

    Orjan