Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

Using uninitialized memory (valgrind report)

(1/3) > >>

oBFusCATed:
Here is what valgrind have spit http://pastebin.com/qscKUNt8
How to reproduce:
1. build
2. cd src && ./update
3. cd devel && export LD_LIBRARY_PATH=`pwd`
4. valgrind ./codeblocks -p debug
5. open codeblocks-unix.cbp

I'm not too familiar with the wxString's implementation, but the function mentioned in the reports is full of constructs that look suspicious.
Examples:

--- Code: ---while (*ptr <= ParserConsts::space_chr)
    ++ptr;
...
while (*(ptr+1) == ParserConsts::ptr_chr)
{
     baseArgs << *ptr; // append one more '*' to baseArgs
     ptr++; // next char
}
...
// skip white spaces and increase pointer
while (   *ptr     != ParserConsts::null
          && *(ptr+1) == ParserConsts::space_chr )
{
      ++ptr; // next char
}

--- End code ---

I'm not familiar with this code, so it will be good if someone could look this up.

ollydbg:
Can you tell me what is context of your test?
Did you use a 64 bit Linux? or 32 bit Linux? --->looking at your log, it looks like you are using 64bit.
32 bit wxWidgets or 64 bit wxWidgets library?
Did you use 2.8.12 version or 2.9.x version of wxWidgets?
I believe that the wxString implementation has changed from 2.8 -> 2.9+, this means using a raw pointer(usually wxChar *) will cause problems. Different system now use different kind of wxString.
See my related post here:http://forums.codeblocks.org/index.php/topic,18353.msg125462.html#msg125462

ollydbg:
Ok, besides the potential issue about wxString in 2.9.x+, I found that the issue reported is definitely related to an unsafe pointer access.

Look at the code snippet:


--- Code: ---bool ParserThread::GetBaseArgs(const wxString& args, wxString& baseArgs)
{
    const wxChar* ptr = args;  // pointer to current char in args string
    wxString word;             // compiled word of last arg
    bool skip = false;         // skip the next char (do not add to stripped args)
    bool sym  = false;         // current char symbol
    bool one  = true;          // only one argument

    TRACE(_T("GetBaseArgs() : args='%s'."), args.wx_str());
    baseArgs.Alloc(args.Len() + 1);

    // Verify ptr is valid (still within the range of the string)
    while (*ptr != ParserConsts::null)
    {
        switch (*ptr)
        {
        case ParserConsts::eol_chr:
            while (*ptr <= ParserConsts::space_chr)   // this the the line parserthread.cpp:2859 reported by valgrind
                ++ptr;
            break;
        case ParserConsts::space_chr:
        ...

--- End code ---

You see, when we meet an "eol_chr", we are going to run a loop:

--- Code: ---            while (*ptr <= ParserConsts::space_chr)   // this the the line parserthread.cpp:2859 reported by valgrind
                ++ptr;

--- End code ---

You see, we don't check whether we have meet a "ParserConsts::null" in the loop, so I think the simple fix is adding this check. Any ideas?

oBFusCATed:
Gentoo linux 64bit, wxGTK 2.8.12, Codeblocks 9399 or something like this.

If you look at my post you'll see that all code excerpts are from this function.

ollydbg:

--- Quote from: oBFusCATed on October 16, 2013, 12:12:28 pm ---Gentoo linux 64bit, wxGTK 2.8.12, Codeblocks 9399 or something like this.

--- End quote ---
Ok, I see.


--- Quote ---If you look at my post you'll see that all code excerpts are from this function.

--- End quote ---
Yes, there are many "Conditional jump or move depends on uninitialised value(s)" reports from valgrind, the reason is that after the pointer passes the eof (the null character at the end of the string, it becomes Dangling pointer.

Navigation

[0] Message Index

[#] Next page