Summary: | False positive in libstdc++ std::list::push_back | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | ewirch <wirch.eduard> |
Component: | drd | Assignee: | Bart Van Assche <bart.vanassche+kde> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | NOR | ||
Version: | 3.9.0.SVN | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | drd r13688 conflict trace for 0x64341a8 |
Description
ewirch
2013-10-22 11:52:17 UTC
Can you tell me the version number of the Linaro distribution that you are using ? I'd like to install Linaro myself in order to reproduce this. So far I have not yet been able to reproduce this issue with the test program provided above neither on Ubuntu 13.04 nor on openSUSE 12.3. > lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.10
Release: 12.10
Codename: quantal
Ubuntu package versions:
gcc 4:4.7.2-1ubuntu2
g++ 4:4.7.2-1ubuntu2
libstdc++6 4.7.2-2ubuntu1
libc6 2.15-0ubuntu20.2
It looks like setlocale plays an important role. When I change the setlocale line in the test case to:
setlocale(LC_ALL, NULL);
OR
setlocale(LC_ALL, "C");
OR something invalid. DRD will not report any errors.
I found a second value, which will also trigger the error: "German". Both values are reported by
locale -a -v
in the "language" fields on my system. So maybe you first check the locales installed on your test system.
A candidate fix has been checked in on the trunk as r13679. Does that help ? Update: the real fix for this issue is in trunk r13686. Sorry, the same errors are being reported. Eduard, it would help a lot if you could do the following: * Double check that your local copy of the Valgrind Subversion repository is up to date and that Valgrind has been rebuilt and reinstalled properly after the most recent update. * Reproduce this issue. * Copy the first address for which DRD reports a conflicting access. * Rerun the test with the following additional DRD options (where ${addr} is the address that has been copied in the previous step): --read-var-info=yes --ptrace-addr=${addr} * If the new run reports a conflicting access on the same address, store the DRD output in a text file and attach it to this bug ticket. * If the new run reported a conflicting access on a different address, try a few times more until the first reported conflicting access is for the address specified via --ptrace-addr. Created attachment 83073 [details]
drd r13688 conflict trace for 0x64341a8
Sure thing. I made sure I'm using the current code by invoking "svn status -u" and by modifying the version number in configure.ac. After building and installing valgrind --version reports: valgrind-3.9.0.SVN.r13688 Error reports strill occur. Created a trace and attached. Thanks. Apparently an stpcpy() intercept was missing in drd. Such an intercept has been added in r13694. Does that help ? Nice, errors are gone. For future bug reports: is a trace of the conflicting address is enough, or do you need a test case? A test case is preferred. The trick with --ptrace-addr only works if a false positive report is caused by a missing intercept. |