Re: core dumps are HUGE...

On Mar 21, 2006, at 10:40 AM, John-Mark Gurney wrote:
> If someone wants to spend some time investigating this, this looks  
> like
> an interesting puzzle:
> -bash-2.05b$ cat t.c
> int main() { char *p = 0; *p = 5; return 0;}
> -bash-2.05b$ cc -static -o t t.c
> -bash-2.05b$ ./t
> Segmentation fault (core dumped)
> -bash-2.05b$ ls -l t t.core
> -rwxr-xr-x  1 jmg  jmg  179737 Mar 21 10:36 t
> -rw-------  1 jmg  jmg  50049024 Mar 21 10:36 t.core
>
> I first read that as 5megs, but it turns out that it's 50megs in size!
> A 50 meg core dump for a static program that does nothing?  Though I
> also have questsions about a 179k program file size for something that
> doesn't call any functions...
>
> Now the interesting part is that dynamicly linked:
> -bash-2.05b$ cc -o t t.c
> -bash-2.05b$ ./t
> Segmentation fault (core dumped)
> -bash-2.05b$ ls -l t t.core
> -rwxr-xr-x  1 jmg  jmg    4615 Mar 21 10:38 t
> -rw-------  1 jmg  jmg  303104 Mar 21 10:38 t.core
>
> only 303k...  Still on the hefty side of things for a program that
> just cores, but better than static's 50megs...

When did you last update this system?  I expect the large core dump  
is due to the 16 MB chunk size for older versions of jemalloc.  3  
chunks would add up to about the right amount, though I'd only expect  
there to be 2 chunks for that example program, so I'm guessing that  
you're running on i386, and that there is nearly 16 MB of padding on  
the heap in order to get the first chunk properly aligned.  The  
version of malloc I checked in late last week uses a 2 MB chunk size,  
so the core size should be much smaller.

The core dump from the static binary is probably much smaller because  
nothing ever calls malloc (no dynamic loader in the mix).

Jason