Bug 816244
| Summary: | tsearch conditional jump or move depends on uninitialized value | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jeff Law <law> |
| Component: | valgrind | Assignee: | Mark Wielaard <mjw> |
| Status: | CLOSED ERRATA | QA Contact: | qe-baseos-tools-bugs |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.3 | CC: | asersen, dspurek, fche, jsynacek, jvcelak, mcermak, mfranc, mjw, mnewsome |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | s390x | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | 3.8.1-3.1.el6 | Doc Type: | Bug Fix |
| Doc Text: |
On s390 valgrind could report an "Conditional jump or move depends on uninitialised value(s)" warning for the tsearch function in glibc. This version includes a standard suppression for this warning so it is no longer reported.
|
Story Points: | --- |
| Clone Of: | 816168 | Environment: | |
| Last Closed: | 2013-02-21 08:50:58 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jeff Law
2012-04-25 15:39:43 UTC
This might be a false positive: http://0-code.google.com.library.metmuseum.org/p/drmemory/issues/detail?id=162 I've double checked and indeed this is a false positive.
The line in question:
Breakpoint 8, maybe_split_for_insert (key=0x3ffffb02f80,
vrootp=<value optimized out>, compar=0x4b664b5518 <known_compare>)
at tsearch.c:177
177 if (parentp != NULL && (*parentp)->red)
(gdb) ptype *parentp
type = struct node_t {
const void *key;
struct node_t *left;
struct node_t *right;
unsigned int red : 1;
} *
On the s390x (and possibly other architectures), we load (*parentp)->red as a word, then test the word is zero/nonzero.
The memory is set here:
281 q = (struct node_t *) malloc (sizeof (struct node_t));
282 if (q != NULL)
283 {
284 *nextp = q; /* link new node to old */
285 q->key = key; /* initialize new node */
286 q->red = 1;
287 q->left = q->right = NULL;
=> 0x4b6649ab5e <__tsearch+430>: oi 24(%r2),128
Valgrind (quite reasonably) still considers the memory at this location undefined as this instruction just sets a single bit at the memory location. Thus when we load & test the full word later valgrind complains.
In an ideal world, valgrind would suppress this error. Reassigning to valgrind so that its suppressions can be updated.
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. *** Bug 750272 has been marked as a duplicate of this bug. *** How does one setup ldapsearch so that one can run this testcase? Is this s390 specific or does it also happen on other arches? I don't really recall how much about this other than it is definitely specific so s390[x]. You might look at c#2 for bz 750272 as that might be a reasonable testcase. Clearly I was able to trigger based on c#3 of this BZ. I don't recall doing anything particularly special. Jeff OK, the simple replicator is just: $ valgrind netstat On s390x That will generate: ==44073== Conditional jump or move depends on uninitialised value(s) ==44073== at 0x4935F12B9C: tsearch (in /lib64/libc-2.12.so) Also with valgrind-3.8.1-2.1.el6.s390x It doesn't happen on x86_64. So adding the following suppression would work around it:
{
s390x-tsearch-node_t-red
Memcheck:Cond
fun:tsearch
obj:/lib64/libc-2.12.so
}
As a workaround just put that in a file called s390-tsearch.supp and run:
$ valgrind --suppressions=s390-tsearch.supp netstat
And there will be no more warnings.
Just for the record, this is the assembly for the test that triggers the warning:
174
175 /* If the parent of this node is also red, we have to do
176 rotations. */
177 if (parentp != NULL && (*parentp)->red)
0x0000004935f12a64 <+180>: ltgr %r8,%r8
0x0000004935f12a68 <+184>: je 0x4935f12af4 <__tsearch+324>
0x0000004935f12a6c <+188>: lg %r2,0(%r8)
0x0000004935f12a72 <+194>: ltg %r3,24(%r2)
0x0000004935f12a78 <+200>: jhe 0x4935f12af4 <__tsearch+324>
0x0000004935f12b90 <+480>: lg %r3,0(%r10)
0x0000004935f12b96 <+486>: ltg %r4,24(%r3)
=> 0x0000004935f12b9c <+492>: jhe 0x4935f12c08 <__tsearch+600>
178 {
And this is the node_t initialization code:
281 q = (struct node_t *) malloc (sizeof (struct node_t));
0x0000004935f12b2a <+378>: lghi %r2,32
0x0000004935f12b2e <+382>: brasl %r14,0x4935e28528 <malloc@plt>
282 if (q != NULL)
0x0000004935f12b34 <+388>: ltgr %r2,%r2
0x0000004935f12b38 <+392>: je 0x4935f12c08 <__tsearch+600>
283 {
284 *nextp = q; /* link new node to old */
0x0000004935f12b3c <+396>: stg %r2,0(%r11)
285 q->key = key; /* initialize new node */
0x0000004935f12b42 <+402>: lg %r4,168(%r15)
0x0000004935f12b48 <+408>: stg %r4,0(%r2)
286 q->red = 1;
0x0000004935f12b5e <+430>: oi 24(%r2),128
287 q->left = q->right = NULL;
0x0000004935f12b4e <+414>: lghi %r5,0
0x0000004935f12b52 <+418>: stg %r5,16(%r2)
0x0000004935f12b58 <+424>: stg %r5,8(%r2)
288
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0347.html |