Debugger stops program when stepping from the opening brace line to the first line of the function.

[Niko Sams]

Well, if the problem is fixed in gdb now it's fine.

thanks for your investigation.

Niko

On Tue, Jan 10, 2012 at 23:03, Morten Volden <mvolden2 at gmail.com> wrote:
> I was not able to find a package with debug symbols for gdb for my
> distro (Ubuntu) :-(
>
> I tried out one of the more recent CVS versions of gdb (weekly
> shapshot of 7.4.50 (20120103)). It seems to handle the execptions from
> the python code more gracefully:
>
> (gdb) -var-create --thread 1 --frame 0 var21 @ "line"
> ^done,name="var21",numchild="0",value="<error reading variable: Cannot
> access memory at address 0x7ffeffffffe9>{_M_dataplus =
> {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No
> data fields>}, <No data fields>}, _M_p = 0x7fff00000001 <Address
> 0x7fff00000001 out of
> bounds>}}",type="std::string",thread-id="1",displayhint="string",dynamic="1",has_more="0"
>
> @Niko: Are you still interested in a backtrace of this? If so, I'll
> try to see if I can get a hold of the debug symbols somewhere (or
> build a version matching the 7.3-2011.08 version my distro is
> running). Otherwise I'll just leave this for now.
>
> /Morten
>
> 2012/1/3 Morten Volden <mvolden2 at gmail.com>:
>> Like you said: it is probably the std::string pretty printer that is
>> the problem.
>> So I started looking into the pretty printer for std::string myself.
>> Now the to_string function for std::string looks like this:
>>
>>    def to_string(self):
>>        # Make sure &string works, too.
>>        type = self.val.type
>>        if type.code == gdb.TYPE_CODE_REF:
>>            type = type.target ()
>>
>>        # Calculate the length of the string so that to_string returns
>>        # the string according to length, not according to first null
>>        # encountered.
>>        ptr = self.val ['_M_dataplus']['_M_p']
>>        realtype = type.unqualified ().strip_typedefs ()
>>        reptype = gdb.lookup_type (str (realtype) + '::_Rep').pointer ()
>>        header = ptr.cast(reptype) - 1
>>        len = header.dereference ()['_M_length']
>>        if hasattr(ptr, "lazy_string"):
>>            return ptr.lazy_string (length = len)
>>        return ptr.string (length = len)
>>
>>
>> So I injeted the following code into the pretty printer:
>>
>>        return 'The pointer is %s' % str(ptr)
>>
>>
>> Which gave the following when stepping into the function parseConfigFile:
>> ....
>>    void parseConfigFile(std::string const& filename)
>>    {
>>        std::ifstream is(filename.c_str());
>>
>>        std::string line;
>> ....
>>
>>
>> filename "The pointer is 0x603028
>> \"/home/mvo/projects/projectFileGeneratorII/test/.kdev4/builddirproject.kdev4\""
>> is           {...}
>> line        "The pointer is 0x7fff00000001 <Address 0x7fff00000001 out
>> of bounds>"
>>
>> Clearly there is a problem with the pointer for the variable 'line'
>> I changed the code for the pretty printer for std::string to the code
>> below, and it works like a charm.
>>
>>    def to_string(self):
>>        # Make sure &string works, too.
>>        type = self.val.type
>>        if type.code == gdb.TYPE_CODE_REF:
>>            type = type.target ()
>>
>>        # Calculate the length of the string so that to_string returns
>>        # the string according to length, not according to first null
>>        # encountered.
>>        ptr = self.val ['_M_dataplus']['_M_p']
>>        realtype = type.unqualified ().strip_typedefs ()
>>        reptype = gdb.lookup_type (str (realtype) + '::_Rep').pointer ()
>>        header = ptr.cast(reptype) - 1
>>        len = header.dereference ()['_M_length']
>>        if hasattr(ptr, "lazy_string"):
>>            try:
>>                ret = ptr.lazy_string (length = len)
>>            except BaseException:
>>                ret = 'Not initialized string'
>>            return ret
>>        return ptr.string (length = len)
>>
>> My knowledge of python is somewhat limited so this is perhaps not the
>> correct way to fix the problem?
>>
>>
>> /Morten
>>
>> 2012/1/2 Niko Sams <niko.sams at gmail.com>:
>>> On Sun, Jan 1, 2012 at 17:53, Morten Volden <mvolden2 at gmail.com> wrote:
>>>> Okay.
>>>>
>>>> Managed to reproduce the crash when running gdb in gdb. All steps
>>>> performed before crash AND the backtrace here:
>>> perfect :D
>>>>
>>>> http://pastebin.com/HLLEDCjs
>>> oh that's without gdb debug symbols. Please install them and do the same again.
>>>
>>> Niko
>>>
>>> --
>>> KDevelop-devel mailing list
>>> KDevelop-devel at kdevelop.org
>>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>
>>
>>
>> --
>> - When the split is pulled, mr. Grenade is no longer our friend
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel