status porting kde2 - ld crashes

status porting kde2 - ld crashes

[Ralf Habacker]

Hi Paul,

The current state on cpmpiling kde2 is, that kdesupport and kdecore are
compiled, but while compiling kdeui the linker crashes after consuming 390
MB RAM. I have looked in the source and found that it crashes in
bfd_find_target() (see below).

Do you have any ideas, what I can do ?

Regards

Ralf

const bfd_target *
bfd_find_target (target_name, abfd)
     const char *target_name;
     bfd *abfd;
{
  const char *targname;
  const bfd_target *target;

  if (target_name != NULL)
    targname = target_name;
  else
    targname = getenv ("GNUTARGET");

  /* This is safe; the vector cannot be null */
  if (targname == NULL || strcmp (targname, "default") == 0)
    {
      abfd->target_defaulted = true;
      if (bfd_default_vector[0] != NULL)
	abfd->xvec = bfd_default_vector[0];
      else
	abfd->xvec = bfd_target_vector[0];
      return abfd->xvec;
    }
--crashes on setting.....---------------------------
  abfd->target_defaulted = false;
----------------------------------------------------

  target = find_target (targname);
  if (target == NULL)
    return NULL;

  abfd->xvec = target;
  return target;
}


Ralf Habacker
EMail: Ralf@habacker.de
       Ralf.Habacker@saght.tessag.com

Re: status porting kde2 - ld crashes

[Nick Clifton]

Hi Ralf,

> The current state on cpmpiling kde2 is, that kdesupport and kdecore are
> compiled, but while compiling kdeui the linker crashes after consuming 390
> MB RAM. I have looked in the source and found that it crashes in
> bfd_find_target() (see below).
> 
> Do you have any ideas, what I can do ?

Presumably 'abfd' is NULL ?  bfd_find_target is not supposed to be
called with a NULL bfd parameter so it is the caller's fault that this
crash is happening.  Can you generate a stack backtrace for the even
and find out who the parents and grandparents are ?

It certainly sounds like a memory exhaustion problem, possibly from an
inifinite loop somewhere, so maybe the stack backtrace will show this
up as well.

Cheers
        Nick

AW: status porting kde2 - ld crashes

[Ralf Habacker]

Hi Nick
> Hi Ralf,
>
> > The current state on cpmpiling kde2 is, that kdesupport and kdecore are
> > compiled, but while compiling kdeui the linker crashes after
> consuming 390
> > MB RAM. I have looked in the source and found that it crashes in
> > bfd_find_target() (see below).
> >
> > Do you have any ideas, what I can do ?
>
> Presumably 'abfd' is NULL ?  bfd_find_target is not supposed to be
> called with a NULL bfd parameter so it is the caller's fault that this
> crash is happening.  Can you generate a stack backtrace for the even
> and find out who the parents and grandparents are ?
>
> It certainly sounds like a memory exhaustion problem, possibly from an
> inifinite loop somewhere, so maybe the stack backtrace will show this
> up as well.
>
it is a memory exhaustion problem.
I have recognized currently that in an run xmalloc is called from
pe_walk.._symbols and in xmalloc the application is canceld because of
returning null pointer.
The problem is that in this fault case the whole cygwin doesn't work, that
means another bash shells hangs.

Regards

> Cheers
>         Nick
>
>

AW: status porting kde2 - ld crashes

[Ralf Habacker]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

> -----Ursprüngliche Nachricht-----
> Von: binutils-owner@sources.redhat.com
> [ mailto:binutils-owner@sources.redhat.com]Im Auftrag von Ralf Habacker
> Gesendet am: Donnerstag, 31. Mai 2001 09:28
> An: Binutils
> Betreff: Re: status porting kde2 - ld crashes
>
> Hello Ralf,
>
> Ralf Habacker <Ralf.Habacker@saght.tessag.com> wrote on Wednesday, May 30,
> 2001:
>
> RH> Hi Paul,
> RH> The current state on cpmpiling kde2 is, that kdesupport and
> kdecore are
> RH> compiled, but while compiling kdeui the linker crashes after consuming
> 390
> RH> MB RAM. I have looked in the source and found that it crashes in
> RH> bfd_find_target() (see below).
>
> RH> Do you have any ideas, what I can do ?
>
>     My guess is that it crashes just due to vm exhaustion (i.e. NULL
> from malloc returned somewhere and passed there). I also can imagine I
> know the reason why so much core is used at all - due to the way
> virtual inline functions are handled by ld (remember, auto-import
> problem was also related to this). The virtual inlines are spewed into
> comdat (aka linkonce) sections, duplicated multiple times in object
> files/ It seems that ld sifts them into non-optimal way: first, loads
> them all together and only them starts hard shuffling to get rid of
> duplicates, instead of doing the check on load. I faced the problem,
> of course, but my solution was to split big dll into bunch of small
> ones. I understand that's not the solution in your case, but it worked
> for me, so I never really tried to test validity of the hypothesis or
> fix it.
>
>

Does anyone have an idea what to do ?

Regards Ralf