search for: emalloc

...ylvain.gault at gmail.com> I found something suspicious while hunting another bug a while ago. The conditions for that bug to occur seems quite hard to meet, but it's still code quality improvement. See the commit message for details. Sylvain Gault (1): efi: Suspicious size reduction in emalloc efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) -- 1.8.5.3

...il.com>: > > From: Sylvain Gault <sylvain.gault at gmail.com> > > > > It looks like git-send-email messed the headers when changing the sender. And there was no actual patch ( no unified diff output ) in that e-mail. Please rerun providing '[PATCH] Potential bug in emalloc' Groeten Geert Stappers -- Leven en laten leven

...eded. This closes bug #39. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/main.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/efi/main.c b/efi/main.c index 0e6b137..94878f9 100644 --- a/efi/main.c +++ b/efi/main.c @@ -691,10 +691,8 @@ EFI_STATUS emalloc(UINTN size, UINTN align, EFI_PHYSICAL_ADDRESS *addr) /* Low-memory is super-precious! */ if (end <= 1 << 20) continue; - if (start < 1 << 20) { - size -= (1 << 20) - start; + if (start < 1 << 20) start = (1 << 20); - } aligned = (start...

...ylvain Gault <sylvain.gault at gmail.com> >> > >> >> It looks like git-send-email messed the headers when changing the sender. > > And there was no actual patch ( no unified diff output ) in that e-mail. > > Please rerun providing '[PATCH] Potential bug in emalloc' > > > Groeten > Geert Stappers This was on purpose. This mail is the cover letter. Because not everything I wanted to say was good to put in the commit message. There is only one patch. Maybe I should have annotated the commit mail? And gmail sent the previous mail from sylvain.g...

2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: > From: Sylvain Gault <sylvain.gault at gmail.com> > It looks like git-send-email messed the headers when changing the sender.

2014-02-13 4:04 UTC+01:00, Sylvain Gault <sylvain.gault at gmail.com>: > 2014-02-13 3:20 UTC+01:00, celelibi at gmail.com <celelibi at gmail.com>: >> From: Sylvain Gault <sylvain.gault at gmail.com> >> > > It looks like git-send-email messed the headers when changing the sender. > Actually this was correct. It's the git-send-email way to specify the

...= { 0x800, (uint64_t *)0 }; +struct dt_desc gdt = { 0x7ff, (uint64_t *)0 }; struct dt_desc idt = { 0, 0 }; static inline EFI_MEMORY_DESCRIPTOR * @@ -852,12 +852,12 @@ static int build_gdt(void) EFI_STATUS status; /* Allocate gdt consistent with the alignment for architecture */ - status = emalloc(gdt.limit, __SIZEOF_POINTER__ , (EFI_PHYSICAL_ADDRESS *)&gdt.base); + status = emalloc(gdt.limit + 1, __SIZEOF_POINTER__ , (EFI_PHYSICAL_ADDRESS *)&gdt.base); if (status != EFI_SUCCESS) { printf("Failed to allocate memory for GDT, bailing out\n"); return -1; } - memset(g...

Can anyone verify that Ferret should work correctly on 64 bit Red Hat ES 4? The test suite gets the following segfault: ........................../unit/../unit/analysis/../../unit/index/../../unit/store/../../unit/search/tc_filter.rb:20: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [x86_64-linux] This is with version "ferret-0.9.4" on an AMD Dual Opteron 270. -- Posted via

...eclaration] 189 | longjmp(&load_error_buf, 1); | ^~~~~~~ syslinux/efi/main.c: In function ?build_gdt?: syslinux/efi/main.c:907:75: warning: taking address of packed member of ?struct dt_desc? may result in an unaligned pointer value [-Waddress-of-packed-member] 907 | status = emalloc(gdt.limit, __SIZEOF_POINTER__ , (EFI_PHYSICAL_ADDRESS *)&gdt.base); | ^~~~~~~~~ syslinux/efi/main.c: In function ?efi_main?: syslinux/efi/main.c:1390:7: warning: implicit declaration of function ?setjmp? [-Wimplicit...

...some that yell: httpd in malloc(): warning: recursive call Those are followed closely by: [Mon Sep 29 01:10:57 2003] [notice] child pid 88809 exit signal Segmentation fault (11) And then it repeats, frequently saying these as well: httpd in free(): warning: page is already free FATAL: emalloc(): Unable to allocate 40 bytes Allowed memory size of 8388608 bytes exhausted (tried to allocate 10 bytes) httpd in free(): warning: chunk is already free My logs are filling up with these, and I'm not sure where to look. Crossreferencing the times with vhost error logs and access logs is...

...mpiling heimdal/lib/roken/base64.c with host compiler Compiling heimdal/lib/roken/ct.c with host compiler Compiling heimdal/lib/roken/hex.c with host compiler Compiling heimdal/lib/roken/bswap.c with host compiler Compiling heimdal/lib/roken/dumpdata.c with host compiler Compiling heimdal/lib/roken/emalloc.c with host compiler Compiling heimdal/lib/roken/ecalloc.c with host compiler Compiling heimdal/lib/roken/getarg.c with host compiler Compiling heimdal/lib/roken/get_window_size.c with host compiler Compiling heimdal/lib/roken/getdtablesize.c with host compiler Compiling heimdal/lib/roken/h_errno.c...