Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Sat, 23 Jun 2012 17:29:01 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Conditional jump or move depends on uninitialised value(s)

Not sure whether these valgrind complains are valid or not, but I
thought I'll post it anyway.

With Valgrind-3.6.1 and

$ ./john --list=build-info
Version: 1.7.9-jumbo-5+unstable
Build: linux-x86-sse2
Arch: 32-bit LE
$JOHN is ./
Rec file version: REC3
CHARSET_MIN: 32 (0x20)
CHARSET_MAX: 126 (0x7e)
CHARSET_LENGTH: 8
gcc version: 4.6.3

(latest git with aab646b42afe93ca909ba1a99bc0e2a1b027a79d reverted)

I ran

$ valgrind --leak-check=full --track-origins=yes --show-reachable=yes \
./john --test=20 2>&1 | tee  valgrind-lc-to-sr-test20

and got

==18104== Conditional jump or move depends on uninitialised value(s)
==18104==    at 0x44A803A7: ____strtoul_l_internal (in /lib/libc-2.14.90.so)
==18104==    by 0x13D78307: ???
==18104==  Uninitialised value was created by a stack allocation
==18104==    at 0x80BC6B0: sha1_fmt_binary (rawSHA1_ng_fmt.c:186)
==18104==
==18104== Conditional jump or move depends on uninitialised value(s)
==18104==    at 0x44A803A7: ____strtoul_l_internal (in /lib/libc-2.14.90.so)
==18104==    by 0x13D76E07: ???
==18104==  Uninitialised value was created by a stack allocation
==18104==    at 0x80BC6B0: sha1_fmt_binary (rawSHA1_ng_fmt.c:186)
==18104==

and

==18104== Conditional jump or move depends on uninitialised value(s)
==18104==    at 0x805C810: crypt_all (trip_fmt.c:303)
==18104==    by 0x80D73F9: fmt_self_test (formats.c:102)
==18104==    by 0x80D0027: benchmark_format (bench.c:138)
==18104==    by 0x80D08BE: benchmark_all (bench.c:449)
==18104==    by 0x80DAEA3: john_run (john.c:835)
==18104==    by 0x80DB4DA: main (john.c:1046)
==18104==  Uninitialised value was created by a heap allocation
==18104==    at 0x4007D89: malloc (vg_replace_malloc.c:236)
==18104==    by 0x80DE66C: mem_alloc (memory.c:54)
==18104==    by 0x80DE77F: mem_alloc_tiny (memory.c:84)
==18104==    by 0x805B9A8: init (trip_fmt.c:130)
==18104==    by 0x80D7163: fmt_init (formats.c:31)
==18104==    by 0x80D07E7: benchmark_all (bench.c:388)
==18104==    by 0x80DAEA3: john_run (john.c:835)
==18104==    by 0x80DB4DA: main (john.c:1046)
==18104==
==18104== Conditional jump or move depends on uninitialised value(s)
==18104==    at 0x804C768: DES_bs_set_key (DES_bs.c:193)
==18104==    by 0x805CA68: crypt_all (trip_fmt.c:391)
==18104==    by 0x80D73F9: fmt_self_test (formats.c:102)
==18104==    by 0x80D0027: benchmark_format (bench.c:138)
==18104==    by 0x80D08BE: benchmark_all (bench.c:449)
==18104==    by 0x80DAEA3: john_run (john.c:835)
==18104==    by 0x80DB4DA: main (john.c:1046)
==18104==  Uninitialised value was created by a heap allocation
==18104==    at 0x4007D89: malloc (vg_replace_malloc.c:236)
==18104==    by 0x80DE66C: mem_alloc (memory.c:54)
==18104==    by 0x80DE77F: mem_alloc_tiny (memory.c:84)
==18104==    by 0x805B9A8: init (trip_fmt.c:130)
==18104==    by 0x80D7163: fmt_init (formats.c:31)
==18104==    by 0x80D07E7: benchmark_all (bench.c:388)
==18104==    by 0x80DAEA3: john_run (john.c:835)
==18104==    by 0x80DB4DA: main (john.c:1046)
==18104==

The leak summary isn't that worrying IMHO:

==18104== LEAK SUMMARY:
==18104==    definitely lost: 448 bytes in 18 blocks
==18104==    indirectly lost: 0 bytes in 0 blocks
==18104==      possibly lost: 0 bytes in 0 blocks
==18104==    still reachable: 7,561 bytes in 19 blocks
==18104==         suppressed: 0 bytes in 0 blocks

If anyone wants to see more details, please let me know.

To avoid the question whether this is for magnum-jumbo or bleeding:
As long as the next jumbo isn't released I don't care about bleeding.

Frank

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.