public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* 971016: EH frame_init trouble on Sparc
@ 1997-10-22  3:11 Teemu Torma
  1997-10-22  8:50 ` H.J. Lu
  1997-11-01 20:11 ` Jeffrey A Law
  0 siblings, 2 replies; 4+ messages in thread
From: Teemu Torma @ 1997-10-22  3:11 UTC (permalink / raw)
  To: egcs

I attempted to throw exceptions in a large C++ application
using snapshot 971016, and ran into trouble.

The problem is that find_fde calls frame_init if pc_begin is zero.
However, frame_init finds the lowest pc_begin as zero, causing
the application to hang and eventually crash.  I think it is doing
initializations over and over again, and frame_init keeps allocating
more and more memory.

The quick fix to make it work at all is to set pc_begin to 1 in
frame_init if it would be zero, but I think the problem lies
somewhere else.  There seems to be a lot of fdes with pc_begin
is zero.

This always happens with the first object in find_fde where ob->count
is over 10000.  The application itself uses ~15 biggish shared C++
libraries and ~20 shared C libraries (Motif etc).

Any pointers where to start looking?

I also noticed that it takes considerable amount of time
to throw the first exception, due to initializations done
at that point.

Teemu




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 971016: EH frame_init trouble on Sparc
  1997-10-22  3:11 971016: EH frame_init trouble on Sparc Teemu Torma
@ 1997-10-22  8:50 ` H.J. Lu
  1997-10-22  9:01   ` Teemu Torma
  1997-11-01 20:11 ` Jeffrey A Law
  1 sibling, 1 reply; 4+ messages in thread
From: H.J. Lu @ 1997-10-22  8:50 UTC (permalink / raw)
  To: Teemu Torma; +Cc: egcs

> 
> I attempted to throw exceptions in a large C++ application
> using snapshot 971016, and ran into trouble.
> 
> The problem is that find_fde calls frame_init if pc_begin is zero.
> However, frame_init finds the lowest pc_begin as zero, causing
> the application to hang and eventually crash.  I think it is doing
> initializations over and over again, and frame_init keeps allocating
> more and more memory.
> 

Please check my email "A frame.c patch". I ran into the same
problem.


H.J.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* 971016: EH frame_init trouble on Sparc
  1997-10-22  8:50 ` H.J. Lu
@ 1997-10-22  9:01   ` Teemu Torma
  0 siblings, 0 replies; 4+ messages in thread
From: Teemu Torma @ 1997-10-22  9:01 UTC (permalink / raw)
  To: H.J. Lu; +Cc: egcs

    From:  hjl@lucon.org (H.J. Lu)
    Date:  Wed, 22 Oct 1997 08:50:25 -0700 (PDT)

    Please check my email "A frame.c patch". I ran into the same
    problem.
    
Thanks, I must have skipped that one.

Teemu


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: 971016: EH frame_init trouble on Sparc
  1997-10-22  3:11 971016: EH frame_init trouble on Sparc Teemu Torma
  1997-10-22  8:50 ` H.J. Lu
@ 1997-11-01 20:11 ` Jeffrey A Law
  1 sibling, 0 replies; 4+ messages in thread
From: Jeffrey A Law @ 1997-11-01 20:11 UTC (permalink / raw)
  To: Teemu Torma; +Cc: egcs

  In message <199710221010.MAA21092@baht.labs.trema.com>you write:
  > I attempted to throw exceptions in a large C++ application
  > using snapshot 971016, and ran into trouble.
  > 
  > The problem is that find_fde calls frame_init if pc_begin is zero.
  > However, frame_init finds the lowest pc_begin as zero, causing
  > the application to hang and eventually crash.  I think it is doing
  > initializations over and over again, and frame_init keeps allocating
  > more and more memory.
I believe this was fixed in the 10/31 snapshot.

jeff

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1997-11-01 20:11 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-10-22  3:11 971016: EH frame_init trouble on Sparc Teemu Torma
1997-10-22  8:50 ` H.J. Lu
1997-10-22  9:01   ` Teemu Torma
1997-11-01 20:11 ` Jeffrey A Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).