View Issue Details

IDProjectCategoryView StatusLast Update
0000687LDMudPortabilitypublic2009-10-05 09:48
Reporterzesstra Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Summary0000687: RfC: Change defaults concerning MALLOC_SBRK / SBRK_OK
DescriptionSeveral of the crashes in the last 1-2 years were caused by memory corruption, because shared libs used different allocators then the driver, although we tried to replace malloc. These usually leads to a rather investment of time for hunting that bugs. I also believe, some of the crashes still not resolved, may be related to this.
(Side note: sbrk/brk() are anyway not POSIX anymore.)

I suggest, that we do not replace the system memory allocator by default in the future. On systems where it does not work at all, our configure script detects it most of the times. But systems, where it basically works and suddenly breaks when some shared library is changed/added, are really a nuisance. And the more optional shared libraries we add in the form of pkg*.c, the worse it gets. Not all libs offer hooks for the allocator functions and some may not use them consistently. I don't believe, that we can invent any reliable form of detection in autoconf for all combinations.
If somebody really wants to use sbrk() and take the risk, he or she can explicitly enable it (but should be aware of a risk).

Suggestion:
3.5: disable MALLOC_SBRK / --enable-malloc-sbrk by default. The allocators can fall back to mmap(), which is available on most systems nowadays. Then we will not interfere with the system allocator, even if we don't replace malloc and some shared libs use the system allocator.
3.3: backport 0000680 and do as described for 3.5
3.2: well... I don't know. The only fall-back in this branch is to use the system allocator by default, which leads to an increased allocator overhead. But I still tend to do that.
TagsNo tags attached.
External Data (URL)

Relationships

related to 0000677 resolvedzesstra LDMud 3.2 starting an SSL-secured connection crashes the driver 
related to 0000671 resolvedzesstra LDMud 3.3 Crash in xml_generate / xml_parse 
parent of 0000680 resolvedzesstra LDMud 3.5 Defective determination of SBRK_OK 

Activities

zesstra

2009-10-05 09:48

administrator   ~0001464

Mhmm. I was a little bit to single-minded: even with mmap it can be dangerous if the replacement of the system allocator is incomplete.
a) if the shared lib uses the system malloc, but our free or vice versa
b) if the shared lib uses our malloc, the system realloc and our free
c) if some lib uses the system strdup() and that uses a non-replaced malloc.
d) if we replace malloc, realloc, free, but some lib uses valloc. In that case, valloc may allocate from the system (if it does not use our malloc) and the memory is free'd by calling our free(). This seems to me the most severe case, because we don't know, what allocation functions in addition to Posix may exist and be used by someone.

a) and b) don't seem very probable, but I don't know if we can rely on it.

So maybe it is just the best, to not replace even with mmap and just live with the fact, that our memory account does not account for memory used by shared libs...

Issue History

Date Modified Username Field Change
2009-10-04 16:01 zesstra New Issue
2009-10-04 16:02 zesstra Relationship added related to 0000677
2009-10-04 16:02 zesstra Relationship added parent of 0000680
2009-10-04 16:03 zesstra Relationship added related to 0000671
2009-10-05 09:48 zesstra Note Added: 0001464