Bring in the 64 bit signal handler fix from latest version. Don't post proprietary code on public domain.
Shruti On 8 Jun 2016 06:23, "Manish" <[email protected]> wrote: > 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 <[email protected]> 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 >> >> >> > > _______________________________________________ > Libunwind-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/libunwind-devel > >
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
