|
From: Julian S. <js...@ac...> - 2009-02-06 12:13:54
|
> >> ==11896== Use of uninitialised value of size 8 > >> ==11896== at 0xC32B140: bn_mul_mont (x86_64-mont.s:151) > >> ==11896== by 0xEFD8ADCFE9793F71: ??? > >> ==11896== by 0x4DC04AA2FB5DAAB0: ??? > >> ==11896== by 0xB18F5B34F8340518: ??? > >> ==11896== by 0x9629706EA81DAD54: ??? > >> ... > > > > That's a hand crafted assembler routine, so unless the author has either > > taken the trouble to setup a traditional x86 stack frame by pushing the > > frame pointer, or has added DWARF declarations to describe how to unwind > > the stack, then valgrind won't be able to unwind out of it. > > > > Can gdb unwind out of that function if you set a break point inside it? > > If I run the program under gdb and set a break point in that function, > gdb can unwind.. > > Breakpoint 1, bn_mul_mont () at x86_64-mont.s:7 > 7 x86_64-mont.s: No such file or directory. > in x86_64-mont.s > Current language: auto; currently asm > (gdb) bt > #0 bn_mul_mont () at x86_64-mont.s:7 > #1 0x00002aaab23cabe5 in BN_mod_mul_montgomery (r=0x2aaab692f220, > a=0x2aaab737a718, b=0x2aaab7374770, mont=0x2aaab7374768, > ctx=0x2aaab698fcc8) at bn_mont.c:159 You need to check that GDB can unwind from that specific instruction, not just from somewhere inside the function. Since the page number will be different, but the page offset will be the same, you need to get GDB to the instruction whose lowest 12 bits is 0x140 (since Valgrind reports 0xC32B140) and see if you can unwind from there. J |