[Bf-committers] Core dump mysterium

Meino Christian Cramer bf-committers@blender.org
Sun, 30 Mar 2003 08:11:47 +0000 (Local time zone must be set--see zic manual page)


From: hans@lambermont.dyndns.org (Hans Lambermont)
Subject: Re: [Bf-committers] Core dump mysterium
Date: Sat, 29 Mar 2003 23:02:51 +0100

> Meino Christian Cramer wrote:
> 
> ...
> > #3  0x400b583a in calloc () from /lib/libc.so.6
> > #4  0x0824d866 in MEM_callocN (len=368, str=0x82fd4b5 "initglobals")
> >     at intern/mallocn.c:224
> > #5  0x08158994 in initglobals () at intern/blender.c:199
> ...
> > Any hint very appreciated.
> 
> intern/mallocn.c:224
>     memh= (MemHead *)calloc(len+sizeof(MemHead)+sizeof(MemTail),1);
> len=368, both sizeofs are probably OK. memh is a valid private pointer.
> So this calloc call is perfectly valid.
> 
> I'd say either your glibc is b0rken or we're looking at a stack-trashing
> type of problem (ie problem is elsewhere). Or ...

  I use to do (roughly) the following when compiling:
---
  unset CFLAGS
  unset CXXFLAGS
  ./bootstrap
  configure --disable-openal
  make all

  as root: make install
---

  So, all optimization that is active while compiling is coming "from
  inside" the source tree (as prefereces or such). I took a look
  (rhymes wins!;) into the output of make: There are some -O2's and
  some -fxxxyyyzzz...but all those are not set by me.

  If the glibc would be b0rken, other programs would have also
  problems (I think). I compiled the whole KDE 3.1.1 with that
  configurations (and optimizations) and have not encountered more
  than the common probs (i.e. config problems and other stuff when
  using such a high complex bunch of software.... ;) but no
  segfaulting.

  Would it be possible, that the blender sources are not
  gcc-3.2.2-ready? I have no experiences concerning this topic (I only
  heard from others that some sources need fixes to run when
  gcc-3.x.x-compiled.......so my question is more like a shoot in the
  dark ;)
  
> What optimization flags are you using ? Does removing any optimization
> help ? If so it's a gcc bug.

  As I do not add any optimization, the "rest" is somewhere burried in
  the blender sources...
  I sthere a "central point" where I can switch them off?
  On the other hand: 
  The same compilation algo is used on the system, where the compiled
  blender runs fine.

  But on the system where blender crashes mostly, there were
  compilations which do work. If the glibc would be the problem, it
  should _always_ crash?!!!  Or...

  Oh, damn ... this is very confusing to me...

  Kind regards,
  Meino 


> Hans
> -- 
> http://lambermont.webhop.org/   () ascii ribbon campaign - against HTML mail,
>                                 /\ vCards and proprietary formats
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>