[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
>