Re: [cdt-dev] strange issue with GDB MI interface with pretty prints

["Ayupov, Andrey" <andrey.ayupov@xxxxxxxxx>]

Sorry for the spam, but I jumped to conclusions too soon. Although, I don't see the issue in that set of commands I sent before, it still crashes with similar diagnostics under slightly different conditions. I will debug more and let you know. :(

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Ayupov, Andrey
Sent: Friday, September 26, 2014 9:45 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] strange issue with GDB MI interface with pretty prints

Simon,

I can probably extract a piece of code that exhibits the crash, if you need it for other purposes than to help me (which I really appreciate by the way :)). See my previous mail, and I think the latest GDB doesn't crash with my code, so I should be fine if I tell users to use that one instead 7.5.1 that had the problem.

Thanks again!
Andrey

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Marchi
Sent: Friday, September 26, 2014 7:05 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] strange issue with GDB MI interface with pretty prints

On 2014-09-25 06:03 PM, Ayupov, Andrey wrote:
> OK, thank you guys for suggestions. I tried them and here what I've found. It is indeed a GDB bug and I could reproduce it in MI mode by sending commands that Eclipse did.
> I also found why in my interactive session it would crash, it is indeed related to the order in which commands were sent. Here are the MI commands that make it crash:
> 
> -environment-cd /mypath
> -enable-pretty-printing
> source /mypath/sc_dt_pretty_print_gdb.cmd
> -file-exec-and-symbols --thread-group i1 
> /mypath/Debug/loop_restruct_test -break-insert --thread-group i1 -d -f
> /mypath/loop_restruct_test.h:89 -break-insert --thread-group i1 -f
> /mypath/loop_restruct_test.h:91 -break-insert --thread-group i1 -f
> /mypath/main.cpp:13 -break-insert --thread-group i1 -t -f main 
> -exec-run --thread-group i1 -exec-continue --thread 1 
> -stack-info-depth --thread 3 -stack-list-locals --thread 3 --frame 0 1
> 
> I believe I should file a bug with GDB, but I am still looking for a workaround... I found that if I remove line "-stack-info-depth --thread 3" then it will not crash. Alternatively, I can keep that line and add line "-thread-info 1" like this:
> -exec-continue --thread 1
> -stack-info-depth --thread 3
> -thread-info 1
> -stack-list-locals --thread 3 --frame 0 1
>  
> This will also keep it alive. In fact this latter case happens when I debug CDT interactively, it sends -thread-info commands for all threads and those happen before -stack-list-locals and that's why it doesn't crash in the CDT debug session. And finally this would still crash it, so it should be a different thread. 
> -exec-continue --thread 1
> -stack-info-depth --thread 3
> -thread-info 3
> -stack-list-locals --thread 3 --frame 0 1
> 
> Any suggestions? Or anything that I can try to help you with suggestions? Thanks!!

Hi Andrey,

Thanks for the details.

However, these commands are very specific to your code. I tried adapting them to a simple test program I use (using pretty printers for the STL types), but couldn't reproduce the crash. Any chance that you can share your code? Otherwise, we will have to find another way to reproduce it.

Simon
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev