[Bug libc/15677] New: Cannot find bounds of current function after executing strrchr in glibc

["vijunag at gmail dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15677

            Bug ID: 15677
           Summary: Cannot find bounds of current function  after
                    executing strrchr in glibc
           Product: glibc
           Version: 2.17
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: vijunag at gmail dot com
                CC: drepper.fsp at gmail dot com

I am trying to debug my executable created from gcc-4.7.2(i686-pc-linux-gnu). 
gdb throws an error "cannot find bounds of current function error" the moment
the program steps into strrchr function and Im not able to debug my executable
after that point. Im not sure if the dwarf records are corrupted or if the
problem is with glibc.  I did disassemble the code and noticed that
epilogue/prologue sequence for the same was replaced with a call to  "86b4900
<__x86.get_pc_thunk.bx>".  I'm also unable to debug the executable after calls
to few functions which have hand-written assembly in glibc.

(gdb) r
Failed to read a valid object file image from memory.
Breakpoint 1, main (argc=5, argv=0xbffff784, env=0xbffff79c) at main.c:205
205    int main(int argc, char **argv, char **env) {
(gdb) n
220        FILE *rva = fopen("/proc/sys/kernel/randomize_va_space", "r+");
(gdb) n
221        if (rva) {
(gdb)
222          int val=0;
(gdb)
224          if (1==fscanf(rva, "%d", &val)) {
(gdb)………………………………….
225        if (val) {
(gdb)
237          fclose(rva);
(gdb)
242          } else if (val) {
(gdb)
273      main_config.argv0short = strrchr(argv[0], '/');
(gdb)
0x08048430 in ?? ()
(gdb)
Cannot find bounds of current function
(gdb)
Cannot find bounds of current function
(gdb)

However if I step-into strrchr function I can continue with debugging.
 I'm not sure if the problem is with gdb or If I'm missing some
compilation
flags while compiling glibc.

Below is the dwarfdump output of strrchr and let me know if it is
missing some important info.

arange starts at 0x1478ac40, length of 0x00000045, cu_die_offset = 0x1a6047c2
187417594 arange end
187417595 COMPILE_UNIT<header overall offset = 0x1a604872>:
187417596 < 0><0x0000000b>  DW_TAG_compile_unit
187417597                     DW_AT_stmt_list             0x01e23163
187417598                     DW_AT_ranges                0x004d5d88
187417599     ranges: 4 at .debug_ranges offset 5070216 (0x004d5d88) (32 bytes)
187417600       [ 0] addr selection 0xffffffff 0x00000000
187417601       [ 1] range entry    0x1478ac90 0x1478ae99
187417602       [ 2] range entry    0x086b4900 0x086b4904
187417603       [ 3] range end      0x00000000 0x00000000
187417604                     DW_AT_name
../sysdeps/i386/i686/multiarch/strrchr.S
187417605                     DW_AT_comp_dir
~/libs/glibc/srcdir/string
187417606                     DW_AT_producer              GNU AS 2.23.1
187417607                     DW_AT_language             
DW_LANG_Mips_Assembler

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-19024-listarch-glibc-bugs=sources.redhat.com@sourceware.org Tue Jun 25 06:58:33 2013
Return-Path: <glibc-bugs-return-19024-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 19101 invoked by alias); 25 Jun 2013 06:58:33 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 18279 invoked by uid 55); 25 Jun 2013 06:58:25 -0000
From: "neleai at seznam dot cz" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15615] Poor quality output from rand_r
Date: Tue, 25 Jun 2013 06:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: neleai at seznam dot cz
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-15615-131-WD3qwNuHbO@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-15615-131@http.sourceware.org/bugzilla/>
References: <bug-15615-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00203.txt.bz2
Content-length: 1453

http://sourceware.org/bugzilla/show_bug.cgi?id\x15615

--- Comment #5 from Ondrej Bilka <neleai at seznam dot cz> ---
On Fri, Jun 14, 2013 at 03:37:30PM +0000, bugdal at aerifal dot cx wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id\x15615
>
> --- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
> On Fri, Jun 14, 2013 at 12:10:59PM +0000, neleai at seznam dot cz wrote:
> > To test rand_r equivalent I wrote a simple generator (which is for
> > mostly to test performance, I did not look for quality.)
> >
> >   movd    (%rdi),%xmm0
> >   movdqa %xmm0,%xmm1
> >
> >   aesenc %xmm0,%xmm1
> >   aesenc %xmm0,%xmm1
> >   aesenc %xmm0,%xmm1
> >   aesenc %xmm0,%xmm1
> >   movd %xmm1, (%rdi)
> >   movd %xmm1, %eax
> >   shr $1, %eax
>
> There's no reason to believe this code will have acceptable period or
> be unbiased. Instead of storing the AES result back to the state, you

Well I wrote above

> > To test rand_r equivalent I wrote a simple generator (which is for
> > mostly to test performance, I did not look for quality.)
Which was only to show that using cryptographic functions is not too
slow. (You can alternatively use CRC32 instruction.)

I am still not convinced that changing implementation is improvement as
everybody which cares about quality uses random_r.

I would accept an warning that rand_r is weak and one should use
random_r.

--
You are receiving this mail because:
You are on the CC list for the bug.