Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 347769

Summary:	CDT debugging is pathologically slow with large app
Product:	[Tools] CDT	Reporter:	Oyvind Harboe <oyvind.harboe>
Component:	cdt-debug	Assignee:	cdt-debug-inbox <cdt-debug-inbox>
Status:	CLOSED DUPLICATE	QA Contact:	Ken Ryall <ken.ryall>
Severity:	normal
Priority:	P3	CC:	cdtdoug, marc.khouzam, pawel.1.piech
Version:	8.0
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Oyvind Harboe

2011-05-31 07:51:09 EDT

Build Identifier: 20110218-0911

I'm debugging an executable which has ca. 2gByte of debug information and CDT is pathologically slow when stepping. Single stepping instructions work fine.

How can I dig up more information on this?

The "gdb" process sits with 100% busy, so I would presume that CDT is asking for "nice to have" information that GDB is having a hard time coming up with.

Emacs GDB does not suffer from any performance issues.

Reproducible: Always

Comment 1 Marc Khouzam

2011-05-31 11:08:51 EDT

Can you include the 'gdb traces' output of your session (you'll find it in the Console view, using the little blue TV icon).

With that, we can see what Eclipse is asking GDB for

Comment 2 Oyvind Harboe

2011-06-01 02:33:24 EDT

(In reply to comment #1)
> Can you include the 'gdb traces' output of your session (you'll find it in the
> Console view, using the little blue TV icon).
> 
> With that, we can see what Eclipse is asking GDB for

I can't include the output, but here are some pathological findings:

The line below is *hundreds* of lines of directories... Can't be good.

050,519 7-environment-directory /home/oyvind/oharboe/wip /home/oyvind/oharboe/wip/.git /home/oyvind/\
oharboe/wip/.git/branches  => 100's of lines

050,666 8-list-thread-groups
050,706 7^done,source-path="/home/oyvind/oharboe/wip:/home/oyvind/oharboe/wip/.git: => 100's of lines

076,683 =library-loaded,id=" => 100's of these

Comment 3 Oyvind Harboe

2011-06-01 06:19:32 EDT

Some more info:


315,858 80-exec-step --thread 1 1
315,858 80^running
315,858 *running,thread-id="all"
315,858 (gdb) 

=> takes 60 seconds(?) to step a single source line here...

426,213 *stopped,reason="end-stepping-range",frame={addr="0x00007fffef1a44a4",func="StorableComp::na\
rrow_cast",args=[{name="i",value="0x3eed930"}],file="xxxx",line="24"},thread-id="1",stopped-threads="al\
l",core="1"
426,213 (gdb) 
426,218 81-stack-info-depth --thread 1 11
426,220 81^done,depth="11"
426,220 (gdb) 
426,303 82-stack-list-frames --thread 1 1 1

Comment 4 Oyvind Harboe

2011-06-01 06:25:37 EDT

If I launch GDB from the command line, the stepping is instantaneous.

My best guess is that the "environment-directory" thing is slowing things down. Can I disable that?

I build w/absolute paths to GCC, so I don't need that do I?


Looks like a long standing problem:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=225708

Comment 5 Marc Khouzam

2011-06-01 09:23:13 EDT

(In reply to comment #4)
> If I launch GDB from the command line, the stepping is instantaneous.
> 
> My best guess is that the "environment-directory" thing is slowing things down.
> Can I disable that?
> 
> I build w/absolute paths to GCC, so I don't need that do I?
> 
> 
> Looks like a long standing problem:
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=225708

Yes, that sounds right.  Details in Bug 225805.  The "environment-directory" command has been removed for the next release.  I believe you can work around this problem by setting up paths in the "Source" tab of the launch
You'll have to look at Bug 225805 to find the exact way.

*** This bug has been marked as a duplicate of bug 225805 ***