-
See https://sourceforge.net/tracker/?func=detail&aid=2923807&group_id=149725&atid=775378 for patches.
2009-12-30 21:49:14 UTC by dtrebbien
-
See https://sourceforge.net/tracker/?func=detail&aid=2923807&group_id=149725&atid=775378 for patches.
2009-12-30 21:48:35 UTC by dtrebbien
-
`duma.c` and `duma_hlp.h` both require changes.
The code for fixing Bug 2923784 ("`_duma_allocate` can't allocate > `DUMA_PAGE_SIZE` bytes") is inspired by parts of code from my `physicalmalloc` project (http://code.google.com/p/physicalmalloc/).
2009-12-30 21:43:31 UTC by dtrebbien
-
Similar to `DUMA_NO_GLOBAL_MALLOC_FREE`, it would be really nice if there were a `DUMA_NO_GLOBAL_NEW_DELETE` option which would disable the DUMA implementations of `new`, `new[]`, `delete`, and `delete[]` from being included into the library.
2009-12-30 21:32:49 UTC by dtrebbien
-
In `duma.c`, the code that follows the comment "I get here if I haven't been able to find a free buffer..." only attempts to allocate `chunkSize` bytes of memory. This means that, executing this block of code, if `userSize` is greater than `chunkSize` (i.e. the user attempts to allocate more than `DUMA_PAGE_SIZE` bytes), only `chunkSize` bytes are allocated, but the call to `_duma_init_slack`...
2009-12-30 21:12:20 UTC by dtrebbien
-
`_duma_realloc` differs from the usual behavior of `realloc` in two ways: one in the case where the pointer parameter is `NULL`; the other in the case where the "new size" parameter is 0.
When the pointer parameter is `NULL`, the behavior of `realloc` per the C standard is to allocate memory as if a call to `malloc` were made. ISO/IEC 9899 says: "If `ptr` is a null pointer, the `realloc`...
2009-12-30 21:02:25 UTC by dtrebbien
-
Added another DUMA configuration environment variable DUMA_MEMCPY_OVERLAP.
Set to 1 to allow overlapping memcpy regions when destination address is less
than source address.
Please integrate this last workaround. With it there is no need to add memmove
implementation to DUMA.
2009-08-03 08:10:22 UTC by nobody
-
This bug is related to the closed bug - ID: 2792252. It addresses the same problems:
There are problems with the fix provided in bug (ID: 2792252) as it doesn't help in situations when memmove
is called by glibc itself.
For example realpath funciton has the following code:
...
/* Careful here, end may be a pointer into extra_buf... */
memmove (&extra_buf[n], end, len + 1);...
2009-08-03 08:06:37 UTC by nobody
