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

Morten Volden mvolden2 at gmail.com
Tue Jan 10 22:03:53 UTC 2012


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




More information about the KDevelop-devel mailing list