View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000687 | LDMud | Portability | public | 2009-10-04 18:01 | 2009-10-05 11:48 |
| Reporter | zesstra | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000687: RfC: Change defaults concerning MALLOC_SBRK / SBRK_OK | ||||
| Description | Several 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. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
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... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-10-04 18:01 | zesstra | New Issue | |
| 2009-10-04 18:02 | zesstra | Relationship added | related to 0000677 |
| 2009-10-04 18:02 | zesstra | Relationship added | parent of 0000680 |
| 2009-10-04 18:03 | zesstra | Relationship added | related to 0000671 |
| 2009-10-05 11:48 | zesstra | Note Added: 0001464 |
