libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] libunwind issue in dwarf_get


From: Manish
Subject: Re: [Libunwind-devel] libunwind issue in dwarf_get
Date: Wed, 8 Jun 2016 18:53:13 +0530

Hi,

Below is some more information on this issue. Kindly reply as this is bit urgent issue we need to solve.

(1) I missed one line at the end of this backtrace, that is as below:
Backtrace stopped: Cannot access memory at address 0x48

(2) gdb shows this error because function "dwarf_get" tries to access memory address 0x48.

(3) To see why it is 72, I check it in the frame 1 as below(as dwarf_get gets inlined)
(gdb) f 1
#1  apply_reg_state (c=0x55681cce70, rs=0x5568069838 <local_addr_space+215176>) at ../contrib/libunwind/src/dwarf/Gparser.c:843
843       ret = dwarf_get (c, c->loc[c->ret_addr_column], &ip);
(gdb) print c->ret_addr_column
$10 = 31
(gdb) print c->loc[c->ret_addr_column]
$11 = {
  val = 72
}
(gdb) 


(4) All values of this structure are as below:

(gdb) print c->loc
$13 = {{
    val = 366818942352
  }, {
    val = 366818942360
  }, {
    val = 366818942368
  }, {
    val = 366818942376
  }, {
    val = 366818942384
  }, {
    val = 366818942392
  }, {
    val = 366818942400
  }, {
    val = 366818942408
  }, {
    val = 366818942416
  }, {
    val = 366818942424
  }, {
    val = 366818942432
  }, {
    val = 366818942440
  }, {
    val = 366818942448
  }, {
    val = 366818942456
  }, {
    val = 366818942464
  }, {
    val = 366818942472
  }, {
    val = 0
  }, {
    val = 8
  }, {
    val = 16
  }, {
    val = 24
  }, {
    val = 32
  }, {
    val = 40
  }, {
    val = 48
  }, {
    val = 366818942536
  }, {
    val = 366818942544
  }, {
    val = 366818942552
  }, {
    val = 366818942560
  }, {
    val = 366818942568
  }, {
    val = 56
  }, {
    val = 366818942584
  }, {
    val = 64
  }, {
    val = 72  <--- This one is used by dwarf_get as memory address, which breaks the execution.
  }, {
    val = 0
  } <repeats 156 times>}
(gdb)


Does this data structure look ok or it has some missing values in between. 
who fills these values and what is the use of them?
and also, is it some libunwind issue which has already been fixed in later versions.I use .99 version .


Your reply is highly appreciated. 

Thanks & Regards,
Manish

On Tue, Jun 7, 2016 at 6:58 PM, Manish <address@hidden> wrote:
Hi Libunwind Dev Team,

I am facing an issue with libunwind in my project, which I am not able to debug much. 
I see so many related posts in the internet, so I feel there is already an  issue with libunwind.
Please suggest solution for this issue.

Libunwind version we are using is : 0.99

The back trace I get is as below:

#0  dwarf_get (val=<optimized out>, loc=..., c=<optimized out>) at ../contrib/libunwind/include/tdep-mips/libunwind_i.h:122
#1  apply_reg_state (c=0x55681cce70, rs=0x5568069838 <local_addr_space+215176>) at ../contrib/libunwind/src/dwarf/Gparser.c:843
#2  0x000000556801c504 in cached_dwarf_find_save_locs (c=0x55681cce70) at ../contrib/libunwind/src/dwarf/Gparser.c:940
#3  0x000000556801c6fc in _ULmips_dwarf_find_save_locs (c=0x55681cce70) at ../contrib/libunwind/src/dwarf/Gparser.c:967
#4  0x000000556801ca70 in _ULmips_dwarf_step (c=0x1214036c8 <raise_interrupt_level+776>) at ../contrib/libunwind/src/dwarf/Gstep.c:35
#5  0x000000556801e97c in _ULmips_step (cursor=0x1214036c8 <raise_interrupt_level+776>) at ../contrib/libunwind/src/mips/Gstep.c:49
#6  0x000000556659a644 in backtrace_unwind (buffer=<optimized out>, size=16) at infra/btrace/./src/backtrace_unwind.c:139
#7  0x0000005566cf7998 in traceback_via_libunwind (buf=0x1255e9401 <tracebuf+49> "", frames2skip=4, space_left_tb=0x55681cbf68) at ../traceback_libunwind.c:53
#8  0x00000001202f210c in traceback_format (buf=0x1255e9401 <tracebuf+49> "", len=<optimized out>, frames2skip=3, somap=<optimized out>) at ../traceback_ios.c:227
#9  0x00000001214116b0 in unix_check_cpuhog (pc=0x1214036c8 <raise_interrupt_level+776>, lr=0x1202c87d4 <random_gen+92>, fp=0x0, platform=0x5566cfc710 "ASR1000") at ../src-unix/unix_watchdog.c:176
#10 0x0000005566ce9560 in catch_linuxsignals (sig=28, siginfo=<optimized out>, uctx=0x55681cdd68) at ../common/unix_signals.c:237
#11 <signal handler called>
#12 0x00000001214036c8 in raise_interrupt_level (new_level=2) at ../src-unix/unix_thread_intr.c:569

Thanks & Regards,
Manish




reply via email to

[Prev in Thread] Current Thread [Next in Thread]