> (gdb) monitor v.info last_error > ==10259== Invalid write of size 4 > ==10259== at 0x28686C: vsnprintf (in /lib/libc-2.12.so) > ==10259== Address 0x4b43040 is 45,120 bytes inside a block of size 65,536 > alloc'd > ==10259== at 0x4005DB9: memalign (vg_replace_malloc.c:727) > ==10259== by 0x4005E68: posix_memalign (vg_replace_malloc.c:876) > > > -The memory for the stack is allocated using memalign and then the upper and > lower parts of it are protected using mprotect, so the stack looks like > this: 16k protected with mprotect, 32K valid for usage, another 16K > protected. The problem happens only in the valid area.
There is an inherent conflict between memcheck and mprotect. On one side, it is desirable that after mprotect which removes all access privileges then memcheck's accounting bits should reflect the current state, including no access. On the other side, it is desirable that after a following mprotect which restores the previous access privileges to the same region, then memcheck's accounting bits should reflect the state *AS IF* those two mprotect() never had occurred. That is, it would be nice if memcheck remembered which bytes were defined and undefined, even though the region "disappeared behind the mprotect NO-ACCESS curtain" for a while. I don't know the exact situation now, but some time in the past it was impossible to have both properties because the accounting bits couldn't handle it. -- ------------------------------------------------------------------------------ How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
