EmbeddedRelated.com
Forums

ElectricFence Exiting: mprotect() failed: Cannot allocate memory

Started by Bill October 13, 2008
On Oct 15, 6:35=A0am, John Reiser <jrei...@BitWagon.com> wrote:

> #include <stdio.h> > > char *f(a) > { > =A0 =A0 =A0 =A0 return 0; > > } > > main() > { > =A0 =A0 =A0 =A0 char *p =3D f(10); > =A0 =A0 =A0 =A0 if (NULL=3D=3Dp) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf("f(10) is NULL.\n"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* fflush(stdout); =A0 =A0THE FIX */ > =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 return *p;}
This is still not very good. What if 'printf' needs to allocate memory to do its job? What if 'fflush' does? In an error handler like this, you are better off calling 'write' directly. DS
Paul Pluzhnikov <ppluzhnikov-nsp@gmail.com> writes:
> Nate Eldredge <nate@vulcan.lan> writes: >>> Is the >>> problem that address 0x2d is not in the ranges shown in pmap? >> >> Well, sort of. 0x2d isn't in that range because that page isn't mapped. >> But it's not supposed to be mapped. The first page of virtual memory is >> always unmapped, so that NULL pointer dereferences generate faults. So >> it's an address that can't possibly be valid. If the crash is inside >> malloc, as you said earlier, then most likely some pointer in malloc's >> data structures got overwritten with 0x0000002d. > > The OP stated that he doesn't actually know that, only deduces this > from lack of printed message (which, as John Reiser aptly suggests, may > be due to naive use of stdout buffering; where stderr was likely > called for). > > Much more likely than pointer being overwritten is that malloc() > in fact returned NULL, and OP then did (an equivalent of):
This means roughly 'it is more likely that the system ran out of memory than that the application contained a programming error'. But this is again a question which can be answered very simply: Check the PC/IP value at the time of the segfault. That's either within malloc (as the OP has repeatedly claimed) or within application code. So, what is it?
David Schwartz <davids@webmaster.com> writes:
> On Oct 15, 6:35&#4294967295;am, John Reiser <jrei...@BitWagon.com> wrote: > >> #include <stdio.h> >> >> char *f(a) >> { >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; return 0; >> >> } >> >> main() >> { >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; char *p = f(10); >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; if (NULL==p) { >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; printf("f(10) is NULL.\n"); >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; &#4294967295; /* fflush(stdout); &#4294967295; &#4294967295;THE FIX */ >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; } >> &#4294967295; &#4294967295; &#4294967295; &#4294967295; return *p;} > > This is still not very good. What if 'printf' needs to allocate memory > to do its job? What if 'fflush' does? In an error handler like this, > you are better off calling 'write' directly.
Another option is to force a segfault, ie assign to the area when the pointer is null. The values of the various CPU registers, especially the program counter, can then (in combination with a disasembler) be used to determine the location of the crash and hence, the condition at the time of the test.
I am trying to use DUMA to find the problem and am getting the
following error when I try to link to the DUMA library:


# LD_PRELOAD=/lib/libduma.a /bin/snmpd &
# ERROR: ld.so: object '/lib/libduma.a' from LD_PRELOAD cannot be
preloaded: ignored.

What can cause this error when using LD_PRELOAD?
> # LD_PRELOAD=/lib/libduma.a /bin/snmpd & > # ERROR: ld.so: object '/lib/libduma.a' from LD_PRELOAD cannot be > preloaded: ignored.
Only an executable object (.e_type is ET_DYN or ET_EXEC) can be pre-loaded. An archive library (*.a) that contains ET_REL files cannot be pre-loaded. --
Bill <jobhunts02@aol.com> writes:

> I am trying to use DUMA to find the problem and am getting the > following error when I try to link to the DUMA library:
It amazes me that in all this time you never managed to answer a simple question: is the crash *in* malloc, or is it in your own code? You are continuing to debug this as if there is malloc corruption, and this will prove futile if the crash is (as I suspect) in your own code instead.
> # LD_PRELOAD=/lib/libduma.a /bin/snmpd & > # ERROR: ld.so: object '/lib/libduma.a' from LD_PRELOAD cannot be > preloaded: ignored.
You can only preload shared libraries. Besides, reading man page for libduma, I see that it uses *exact* same strategy as efence: a guard page after every allocation. So, once you manage to build a shared libduma.so, and preload it; it will most likely fail just like efence did, because the overhead of guard pages is too great for majority of real-world (non-toy) applications. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email.