| Summary: | Possible Memory leak in crypt_r | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Miguel Diaz <tiomiguel> | ||||
| Component: | nss | Assignee: | Elio Maldonado Batiz <emaldona> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 16 | CC: | emaldona, jakub, kdudka, kengert, law, tiomiguel | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-12-23 05:22:05 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Rerant the test with: nspr-4.8.9-2.fc16.x86_64, nss-3.12.10-7.fc16.x86_64, nss-softokn-3.12.10-6.fc16.x86_64, and nss-util-3.12.10-1.fc16.x86_64 My results: ==8548== Memcheck, a memory error detector ==8548== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==8548== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==8548== Command: ./crypt ==8548== ==8548== Conditional jump or move depends on uninitialised value(s) ==8548== at 0x50FEA3F: __stpncpy_sse2_unaligned (strcpy-sse2-unaligned.S:524) ==8548== by 0x4E323E7: __md5_crypt_r (md5-crypt.c:249) ==8548== by 0x4E31E67: crypt_r (crypt-entry.c:97) ==8548== by 0x4005C9: main (in /home/emaldona/BugReproducers/Bug699917/crypt) ==8548== ==8548== Conditional jump or move depends on uninitialised value(s) ==8548== at 0x50FE9A8: __stpncpy_sse2_unaligned (strcpy-sse2-unaligned.S:488) ==8548== by 0x4E323E7: __md5_crypt_r (md5-crypt.c:249) ==8548== by 0x4E31E67: crypt_r (crypt-entry.c:97) ==8548== by 0x4005C9: main (in /home/emaldona/BugReproducers/Bug699917/crypt) ==8548== ==8548== ==8548== HEAP SUMMARY: ==8548== in use at exit: 0 bytes in 0 blocks ==8548== total heap usage: 200,501 allocs, 200,501 frees, 10,423,268 bytes allocated ==8548== ==8548== All heap blocks were freed -- no leaks are possible ==8548== ==8548== For counts of detected and suppressed errors, rerun with: -v ==8548== Use --track-origins=yes to see where uninitialised values come from ==8548== ERROR SUMMARY: 200 errors from 2 contexts (suppressed: 2 from 2) *** This bug has been marked as a duplicate of bug 760262 *** |
Created attachment 495060 [details] Code to reproduce the problem Description of problem: Valgrind points out a possible memory leak while using crypt_r. I reduced it to a tiny program which shows the problem in my system. Version-Release number of selected component (if applicable): $ uname -a Linux MiguelDiaz.a2system 2.6.35.11-83.fc14.i686.PAE #1 SMP Mon Feb 7 06:57:55 UTC 2011 i686 i686 i386 GNU/Linux $ yum info glibc Loaded plugins: langpacks, presto, refresh-packagekit Adding en_US to language list Installed Packages Name : glibc Arch : i686 Version : 2.13 Release : 1 How reproducible: --- Code to reproduce --- #define _GNU_SOURCE #include <stdio.h> #include <string.h> #include <crypt.h> int main() { char *ptr; char res[50] = {0}; char salt[] = "$1$protocHT"; struct crypt_data data; data.initialized = 0; int i; for ( i = 0 ; i < 100 ; ++i ) { ptr = crypt_r("string_to_process", salt, &data); strcpy(res, ptr); } return 0; } --- Code to reproduce end --- Steps to Reproduce: 1. Compile previous source code: $ gcc crypt.c -o crypt -lcrypt 2. Test under valgrind: valgrind --leak-check=full ./crypt 3. See the definitely lost column Actual results: ==9926== 1,700 bytes in 100 blocks are definitely lost in loss record 1 of 1 ==9926== at 0x400677E: malloc (vg_replace_malloc.c:195) ==9926== by 0x6CF00E: _dl_map_object (in /lib/ld-2.13.so) ==9926== by 0x6D94F4: dl_open_worker (in /lib/ld-2.13.so) ==9926== by 0x6D5785: _dl_catch_error (in /lib/ld-2.13.so) ==9926== by 0x6D9BC5: _dl_open (in /lib/ld-2.13.so) ==9926== by 0x891BCA: dlopen_doit (in /lib/libdl-2.13.so) ==9926== by 0x6D5785: _dl_catch_error (in /lib/ld-2.13.so) ==9926== by 0x89235B: _dlerror_run (in /lib/libdl-2.13.so) ==9926== by 0x891C80: dlopen@@GLIBC_2.1 (in /lib/libdl-2.13.so) ==9926== by 0x58EA7AD: ??? (in /lib/libfreebl3.so) ==9926== by 0x58EADF1: NSSLOW_Init (in /lib/libfreebl3.so) ==9926== by 0x571ACDC: __md5_crypt_r (in /lib/libcrypt-2.13.so) ==9926== ==9926== LEAK SUMMARY: ==9926== definitely lost: 1,700 bytes in 100 blocks ==9926== indirectly lost: 0 bytes in 0 blocks ==9926== possibly lost: 0 bytes in 0 blocks ==9926== still reachable: 0 bytes in 0 blocks ==9926== suppressed: 0 bytes in 0 blocks Expected results: ==9926== All heap blocks were freed -- no leaks are possible Additional info: I want to know whether I'm misusing crypt_r or if there is an actual leak.