On Jan 20, 2011, at 4:35 AM CST, john skaller wrote:
> On 20/01/2011, at 3:04 AM, Dave Goodell wrote:
>
>> On Jan 19, 2011, at 9:52 AM CST, john skaller wrote:
>>
>>> On 20/01/2011, at 2:39 AM, Dave Goodell wrote:
>>>
>>>> On Jan 18, 2011, at 10:56 PM CST, john skaller wrote:
>>
>>> I could rewrite the GC so that the stack scan is in a separate subroutine,
>>> and then just exclude that using Valgrinds nice suppression mechanism.
>>
>> Yes, although this doesn't get rid of the uninitialized values, which could
>> potentially propagate elsewhere in your code. It just suppresses error
>> _reporting_
>
> Well there's no way to get rid of these "uninitialised" values. Most are in
> fact initialised.
> The problem is something like: when a subroutine is called the return address
> is pushed
> on the stack, along with callee-save registers.
>
> I suspect Valgrind thinks these are uninitialised values.
Valgrind tracks the V bits (validity bits) for registers too, so the validity
of any pushed register values on the stack will depend on the validity of the
register contents before the push.
> In other cases: consider, I have a data structure:
>
> struct { int x; long y; } a;
>
> on the stack with say 4 bytes padding after 'x'. When I read the 8 byte word
> at address "a" half is uninitialised. I'm not sure what Valgrind would say
> here:
> most of my uninitialised values are Value8.
There is a way to "get rid" of the uninitialized values, one that I posted
earlier in the thread. Try reading over the manual's explanation of how
Valgrind tracks defined/undefined data:
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.machine
And then the section on client requests:
http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq
If you follow that, then I think the best approach is to adapt the client
request code sketch that I posted before for scanning the whole stack:
----8<----
#define RZ_SZB (128)
char *sp = /* stack pointer value */;
char vbits[RZ_SZB] = {0};
VALGRIND_GET_VBITS(sp-RZ_SZB, vbits, RZ_SZB);
VALGRIND_MAKE_MEM_DEFINED(sp-RZ_SZB, RZ_SZB);
/* ... scan the red zone here ... */
VALGRIND_SET_VBITS(sp-RZ_SZB, vbits, RZ_SZB);
----8<----
>> Right. I was thinking this was an external thread or signal handler
>> examining another stack, in which case you would need to scan the whole red
>> zone. But if it all happens as a result of an explicit new/allocate call
>> then scanning the red zone shouldn't be necessary.
>
> Yeah. I'm not sure what happens on x86_64 Unix (OSX, Linux) with signals: I
> have a feeling
> they do not use the applications stack? or do they bump the RSP by the size
> of the redzone
> before calling the handler?
I don't know for sure, although I'm certain there are several people on this
list who could tell you about the mechanism in excruciating detail if they feel
like it. Signals can definitely be handled on a separate signal stack if
SA_ONSTACK is passed to sigaction.
> Anyhow, I've got some other test code exhibiting problems sometimes and not
> others,
> and I'm no closer to a solution. Sometime code works, sometimes it segfaults,
> sometimes it just overwrites the wrong place and I trap the problem and
> report it.
> The behaviour is always the same for the same program, data, and GC tuning
> parameters: the fault is unpredictable but thankfully not intermittent.
>
> Unfortunately running Valgrind is one of the things the bug is sensitive to,
> it runs and hides when running Valgrind :)
That happens sometimes, especially if there are threads in your program because
Valgrind changes the way that threads are scheduled. Valgrind also replaces
the standard malloc and some other routines, which can change the way that they
behave. Hopefully if you can clean up the false positives from your
stack-scanning code then you will be able to find some bugs from the remaining
warnings.
-Dave
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
