This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb 6.1.1 (PPC) crash (long)


On Tue, Sep 07, 2004 at 05:13:41PM +0200, Fabian Cenedese wrote:
> 
> >> >Here's what happens:
> >> >
> >> >(gdb) ptype this
> >> >type = class CMainTask : public CINOSTask {
> >> >  public:
> >> >    CMainTask & operator=(CMainTask const &);
> >> >    virtual ~CMainTask(void);
> >> >      2 [main] gdb 2100 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
> >> >    329 [main] gdb 2100 open_stackdumpfile: Dumping stack trace to gdb.exe.stackdump
> >> 
> >> If anybody is interested in solving this, I can send a small debug-only file
> >> (objcopy --only-keep-debug, ~250KB) and the sources and the processed
> >> Assembler files (gcc -S). I still can't find how to solve this, debugging via
> >> gdb is quite new to me.
> >
> >I'll take a look at it; could you send them to me (off-list)?
> 
> Here it is. The cpp looks... not so good as I tried to comment out as much as
> possible to keep the info small. But I don't know if you even need it. The file
> dbg.x is the one I load into gdb and makes it crash with the above command,
> I just tested this again.
> 
> Thanks for your help.

OK, I can reproduce it.  It looks like a bug in the stab reader. 
Here's the stab; newlines added for clarity but I don't swear I got
them in the right place.

 CMainTask:Tt(0,25)=s148!1,020,(16,31);
   __as::(0,26)=##(0,27)=&(0,25);:RC9CMainTask;2A.;
   CMainTask::(0,28)=##(0,29)=*(0,25);:RC9CMainTask;2A.
	      (0,30)=#(0,25),(0,20),(0,29),(0,1),(0,20);:_._9CMainTask;2A*1;(16,31);
	      (0,31)=##(0,29);:PcUlUl;2A.;
   Action::(0,32)=##(0,20);:;2A*2;(16,31);;;~%(16,31);

We're completely botching up the parsing of the constructor.  The
problem seems to be the presence of constructor, destructor,
constructor.  The bug will be, in current CVS, in stabsread.c around
line 2468 in the has_destructor && has_other case.

It looks like I got the linked list management wrong; I have this
habitual problem with linked lists.  The bug may be pretty easy to spot
but I don't have time to dig for it today.

Hope this helps!

-- 
Daniel Jacobowitz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]