two 4GB mallocs => SEGV
roam at ringlet.net
Thu Oct 28 03:53:47 PDT 2004
On Tue, Oct 26, 2004 at 03:13:16PM +0200, Willem Jan Withagen wrote:
> Peter Pentchev wrote:
> >On Tue, Oct 26, 2004 at 02:47:06PM +0200, Willem Jan Withagen wrote:
> >>Georgi Guninski wrote:
> >>>on a freebsd amd64 box with more than 8GB swap i experience the
> >>>amdkotef64# cat test.c
> >[snip 2 * 4GB malloc]
> >>>amdkotef64# gcc test.c
> >>>amdkotef64# ./a.out
> >>>/: write failed, filesystem is full
> >>>Segmentation fault
> >>These 2 lines stem from the fact that the program is being dumped and
> >>there is not enough space to dump the full size core of that program.
> >>what does swapinfo tell you during the the run of the program???
> >>I ran malloc tests in 4Gb with 5Gb of swap, which it nicely completely
> >>filled, and then in faulted, because there was no more space.
> >>This behaviour can be set, I think. Check man 5 malloc.conf, and check
> >>/etc/malloc.conf to see if you've got the X-flag on.
> >But shouldn't malloc() write out an 'out of memory' message before the
> >core dump then? There's no such message in Georgi's output.
> That depends on the flags set with malloc.conf. The X-flag tells you how
> errors are handled. But you are right, it is strange:
> malloc should either return 0, or give a warning.
I looked at the source before posting that - src/lib/libc/stdlib/malloc.c,
and the handling of malloc_xmalloc invokes wrterror(), which writes to
stderr before aborting.
> I think that std-malloc settings were AX for anything before -STABLE.
Actually they were 'AJ', not 'AX', and they were turned off on Sep 7 for
RELENG_5. Georgi's uname shows 5.3-BETA6, which was cut about Sep 23,
so neither 'J' nor 'X' ought to be set by default.
Still, Georgi, can you check if you have a MALLOC_OPTIONS variable or
a /etc/malloc.conf symlink?
> >It's true that when he asked me on Saturday about this, I completely
> >forgot about malloc's X flag, but I don't think he's using it, and even
> >if he were, there ought to be a message there.
> That's why I send him to the man-page. He could even force the settings in
> the testprogram. And check the link!!! it is probably set to something, or
> something is assumed. So better be safe and force it one-selves.
> Could be that the message does not arrive because the out-of-mem trap
> killed it first.... ???
> Perhaps also check /var/log/messages. I remember seeing things there as
Aye, that's a good idea.
> >>I have malloc.conf-> aj, and the program terminates in 3 seconds because
> >>it does not zero the memory.
> >>So pick and choose the behaviour you want.
> >Sure, the question is if this is the result of 'X' or something else :)
> Well given the fact that there are not yet that many big boxes, let alone
> people really wanting to allocate a 4Gb blob, I'm not going to bet the
> usual case of beer on it. :~)
I won't either - seeing as, physical distance considered, Georgi has a much
better chance to find me and hold me up to it :)
Peter Pentchev roam at ringlet.net roam at cnsys.bg roam at FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20041026/7f3763f3/attachment.bin
More information about the freebsd-amd64