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

[Morten Volden]

Hmmmm backtrace does not seem to give anything meaningful - Or maybe
I'm not reading it correctly?

Anybody has any idea what to do?


(gdb) bt full
#0  0x0000000000401116 in TestParse::parseConfigFile
(this=0x7fffffffe06e, filename=...)
    at /home/mvo/projects/testDebug/main.cpp:11
        is = <incomplete type>
        line = {static npos = <optimized out>,
          _M_dataplus = {<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data
fields>},
            _M_p = 0x7fff00000001 <Address 0x7fff00000001 out of bounds>}}
#1  0x0000000000401041 in main (argc=2, argv=0x7fffffffe168) at
/home/mvo/projects/testDebug/main.cpp:36
        test = {<No data fields>}
(gdb)


/Morten


2011/12/30 Morten Volden <mvolden2 at gmail.com>:
> It seems i can:
>
> (gdb)
> -stack-list-arguments --thread 1 --frame 0 0 0 0
> ^done,stack-args=[frame={level="0",args=[name="this",name="filename"]}]
> (gdb)
> -var-create --thread 1 --frame 0 var5 @ "is"
> ^done,name="var5",numchild="0",value="{...}",type="std::ifstream",thread-id="1",has_more="0"
> (gdb)
>  -var-create --thread 1 --frame 0 var6 @ "line"
> Segmentation fault
>
> I'll enable core dumps,retrace the steps again, and post it here.
>
> /Morten
>
> 2011/12/30 Niko Sams <niko.sams at gmail.com>:
>> Ok, gdb crashed:
>> kdevelop(3188)/kdevelop (gdb debugger)
>> GDBDebugger::GDB::processErrored: GDB ERRORED 1
>> (1 = QProcess::Crashed)
>>
>> most probably a bug in gdb; my guess is because of the std::string
>> pretty printer - which you probably
>> don't use when you run in plain gdb.
>>
>> To be sure you need to reproduce the bug:
>> - open GDB tool view
>> - right click and select "Show Internal Commands"
>> - Copy all Contents
>> - Extract the (blue) lines starting with (gdb)
>> - start gdb from commandline and execute exactly those commands
>> - post the output here
>>
>> We had a similar bugreport shortly ago, but the reporter didn't manage
>> to reproduce
>> it in gdb. Hopefully you can :D
>>
>> thanks,
>> Niko
>>
>> On Fri, Dec 30, 2011 at 14:26, Morten Volden <mvolden2 at gmail.com> wrote:
>>> Complete Console output is here:
>>>
>>> http://pastebin.com/tfyMUXab
>>>
>>> /Morten
>>>
>>> 2011/12/30 Niko Sams <niko.sams at gmail.com>
>>>>
>>>> > The output of the 'Show internal commands' in the GDB window is here:
>>>> >
>>>> > http://pastebin.com/4GhwmmB0
>>>> please also post the console output with gdb area enabled in
>>>> kdebugdialog. (execute `kdebugdialog` to change)
>>>>
>>>> > A courious thing: It indicates that a break point is attempted set in a
>>>> > file
>>>> > that belongs to another project (That project was not even loaded during
>>>> > debug session)
>>>> This is correct - all breakpoints listed in Breakpoints tool view are set
>>>> - even
>>>> if they don't belong to an opened project.
>>>> (as you might debug a library or something that you don't have as open
>>>> project - or
>>>> you can even debug without a project open)
>>>>
>>>> Niko
>>>>
>>>> --
>>>> KDevelop-devel mailing list
>>>> KDevelop-devel at kdevelop.org
>>>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>>
>>>
>>>
>>>
>>> --
>>> KDevelop-devel mailing list
>>> KDevelop-devel at kdevelop.org
>>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>>
>>
>> --
>> 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



-- 
- When the split is pulled, mr. Grenade is no longer our friend