Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#30643 - [glibc] valgrind reports invalid read in wcslen

Attached to Project: Arch Linux
Opened by Mr.Magne (Mr.Magne) - Wednesday, 11 July 2012, 17:21 GMT
Last edited by Allan McRae (Allan) - Thursday, 25 October 2012, 00:03 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I'm pretty sure it's an upstream bug, but they recommend to report downstream first.
The following code sample, build with [code]gcc test_wcslen.c[/code] and executed with [code]valgrind ./a.out[/code] reports invalid read (and also Conditional jump or move depends on uninitialised value(s) ).
When the array is statically allocated ther is no invalid read.

Additional info:
* package version(s)
core/glibc 2.16.0-1 (base) [installed]
multilib/gcc-libs-multilib 4.7.1-4.1 [installed]
extra/valgrind 3.7.0-3 [installed]

* config and/or log files etc.
x86_64

Steps to reproduce:
gcc test_wcslen.c
valgrind ./a.out
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 25 October 2012, 00:03 GMT
Reason for closing:  Upstream
Additional comments about closing:  spurious warning by valgrind
Comment by Allan McRae (Allan) - Wednesday, 11 July 2012, 20:59 GMT
Can you please post your valgrind output as well as your processor information. I can not replicate the invalid read.
Comment by Mr.Magne (Mr.Magne) - Thursday, 12 July 2012, 07:31 GMT
Here it is. After a quick look on glibc sources I think it is highly dependent on the architecture (sse2 optimizations and such).
Comment by Allan McRae (Allan) - Thursday, 12 July 2012, 07:42 GMT
Which is why I asked for your processor information (cat /proc/cpuinfo)
Comment by Mr.Magne (Mr.Magne) - Thursday, 12 July 2012, 08:18 GMT
whooops, I should have open my eyes before reading your message, sorry
   cpuinfo (3.1 KiB)
Comment by Allan McRae (Allan) - Thursday, 12 July 2012, 11:59 GMT
I still can not replicate on multiple x86_64 systems... And my look at the glibc code makes me think there is only a single implementation of wcslen on x86_64.

I am very sure this is a false positive. Valgrind has always had issues with wcslen since the optimized versions were added (in glibc-2.15 and unchanged in glibc-2.16...).
Comment by Mr.Magne (Mr.Magne) - Thursday, 12 July 2012, 15:39 GMT
strange... I can replicate this on my laptop (see attached cupinfo).
   cpuinfo2 (1.5 KiB)
Comment by Jason William Walton (jasonww) - Thursday, 12 July 2012, 22:05 GMT
Preprocessed wcslen:

curl http://sprunge.us/XibB -o wcslen.s

Useful if you want line numbers or file a bugreport (somwehere) for easy reproducing.
Comment by Daniel YC Lin (dlin) - Monday, 16 July 2012, 03:41 GMT
I've similar problems on simplified t.c.
int main() {
return 0;
}

Where attached file t.log is result of valgrind with parameter --track-origins=yes.

Version info:

glibc 2.16.0-2
valgrind 3.7.0-3
gcc-libs-multilib 4.7.1-4.1
Linux u40 3.4.4-3-ARCH #1 SMP PREEMPT Tue Jul 3 14:36:44 UTC 2012 x86_64 GNU/Linux
   t.log (1.8 KiB)
Comment by Madura A (maduraa) - Friday, 20 July 2012, 14:33 GMT
The valgrind output I get is attached, I get this for every executable I run using valgrind. With 2.15 I had no problems. I did not use any special arguments when running valgrind just the executable name. It's the same for ls too!

uname -a
Linux trex-j 3.4.5-1-ARCH #1 SMP PREEMPT Mon Jul 16 21:35:54 CEST 2012 x86_64 GNU/Linux
   val (1.7 KiB)
Comment by Chase Geigle (skystrife) - Saturday, 21 July 2012, 23:19 GMT
I think we may just need an update for the suppressions file for valgrind[1]: likely that this is a false positive again[2].

[1] http://stackoverflow.com/questions/11506370/valgrind-reports-unitialized-values-on-empty-c-program
[2] https://bugzilla.redhat.com/show_bug.cgi?id=798968
Comment by Mr.Magne (Mr.Magne) - Monday, 30 July 2012, 09:13 GMT
Sorry for the late reply but I have no errors with empty main (like Daniel YC Lin), and obviously no errors with every executable (like Madura A).
And I am afraid I don't know how to use the preprocessed file given by Jason William Walton...
Comment by Madura A (maduraa) - Monday, 30 July 2012, 09:53 GMT
I do not get the errors after valgrind was updated, seems it was a problem in valgrind just upgrade from core.
Comment by Daniel YC Lin (dlin) - Tuesday, 31 July 2012, 00:57 GMT
It solved on newer version. I guess, this issue may be closed.

glibc 2.16.0-2
valgrind 3.7.0-4
gcc-libs-multilib 4.7.1-5
linux 3.4.7-1
Comment by Mr.Magne (Mr.Magne) - Tuesday, 31 July 2012, 07:32 GMT
I still have the invalid read (only for the wcslen case)

linux 3.4.6-1
valgrind 3.7.0-4
glibc 2.16.0-2
gcc-libs-multilib 4.7.1-5

installing linux 3.4.7 and rebooting to test it...
EDIT: same problem with linux 3.4.7-1
Comment by Allan McRae (Allan) - Saturday, 11 August 2012, 03:24 GMT
How are things with valgrind 3.8?
Comment by Mr.Magne (Mr.Magne) - Monday, 13 August 2012, 13:04 GMT
Same error

linux 3.4.8-1
valgrind 3.8.0-1
glibc 2.16.0-2
gcc-libs-multilib 4.7.1-5

Loading...