Menu
▾
▴
Re: [Openbts-discuss] OpenBTS-transceiver error on USRP N200
|
From: Nikos B. <nba...@gm...> - 2016-11-29 10:23:22
|
This appears to be a problem within libuhd. You may want to transfer these logs to their mailing list. They may already have an update to this problem. You must have the most recent uhd. With uhd 003.009.002 that I have, I get no such core dump in device::find in either my code or openbts-4.0 or openbts-umts. Haven't tried openbts-5.0, though:( BR, Nikos On Tue, Nov 29, 2016 at 11:57 AM, ty <tyr...@gm...> wrote: > Ah thanks Nikos. Here's the output > > gdb) where > #0 0xb7fdd428 in __kernel_vsyscall () > #1 0xb72d101b in poll () at ../sysdeps/unix/syscall-template.S:81 > #2 0xb455f0a9 in send_dg (ansp2_malloced=0x0, resplen2=0x0, anssizp2=0x0, > ansp2=0x0, anscp=0xbfffded8, gotsomewhere=<synthetic pointer>, > v_circuit=<synthetic pointer>, ns=0, terrno=0xbfffcee8, > anssizp=0xbfffcfa8, ansp=0xbfffcedc, buflen2=0, buf2=0x0, buflen=34, > buf=0xbfffcfc0 "X\354\001", > statp=0xb73a1fc0 <_res>) at res_send.c:1206 > #3 __libc_res_nsend (statp=statp@entry=0xb73a1fc0 <_res>, buf=buf@entry=0xbfffcfc0 > "X\354\001", buflen=34, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0, > ans=ans@entry=0xbfffdab0 "`7\374\260\001", anssiz=anssiz@entry=1024, > ansp=ansp@entry=0xbfffded8, ansp2=ansp2@entry=0x0, nansp2=nansp2@entry > =0x0, > resplen2=resplen2@entry=0x0, ansp2_malloced=ansp2_malloced@entry=0x0) > at res_send.c:576 > #4 0xb455ce05 in __GI___libc_res_nquery (statp=statp@entry=0xb73a1fc0 > <_res>, name=name@entry=0xbfffd1bb "the-jedi-council.", class=class@entry > =1, > type=type@entry=1, answer=answer@entry=0xbfffdab0 "`7\374\260\001", > anslen=anslen@entry=1024, answerp=answerp@entry=0xbfffded8, > answerp2=answerp2@entry=0x0, > nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0, > answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:227 > #5 0xb455d46b in __libc_res_nquerydomain (statp=statp@entry=0xb73a1fc0 > <_res>, name=name@entry=0xbfffe80f "the-jedi-council", > domain=domain@entry=0xb73a2020 <_res+96> "", class=class@entry=1, > type=type@entry=1, answer=answer@entry=0xbfffdab0 "`7\374\260\001", > anslen=anslen@entry=1024, answerp=answerp@entry=0xbfffded8, > answerp2=answerp2@entry=0x0, nanswerp2=nanswerp2@entry=0x0, > resplen2=resplen2@entry=0x0, > answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:591 > #6 0xb455d97f in __GI___libc_res_nsearch (statp=0xb73a1fc0 <_res>, > name=name@entry=0xbfffe80f "the-jedi-council", class=class@entry=1, > type=type@entry=1, > answer=answer@entry=0xbfffdab0 "`7\374\260\001", anslen=anslen@entry=1024, > answerp=answerp@entry=0xbfffded8, answerp2=answerp2@entry=0x0, > nanswerp2=nanswerp2@entry=0x0, resplen2=resplen2@entry=0x0, > answerp2_malloced=answerp2_malloced@entry=0x0) at res_query.c:421 > #7 0xb7fc5222 in __GI__nss_dns_gethostbyname3_r (name=name@entry=0xbfffe80f > "the-jedi-council", af=af@entry=2, result=result@entry=0xbfffe7f8, > buffer=buffer@entry=0xbfffe3c0 "\377\002", buflen=buflen@entry=1024, > errnop=errnop@entry=0xb559f6a8, h_errnop=h_errnop@entry=0xbfffe7f4, > ttlp=ttlp@entry=0x0, canonp=canonp@entry=0x0) at > nss_dns/dns-host.c:192 > #8 0xb7fc5591 in _nss_dns_gethostbyname_r (name=0xbfffe80f > "the-jedi-council", result=0xbfffe7f8, buffer=0xbfffe3c0 "\377\002", > buflen=1024, errnop=0xb559f6a8, > h_errnop=0xbfffe7f4) at nss_dns/dns-host.c:273 > #9 0xb72f272b in __gethostbyname_r (name=0xbfffe80f "the-jedi-council", > resbuf=0xbfffe7f8, buffer=buffer@entry=0xbfffe3c0 "\377\002", > buflen=buflen@entry=1024, > result=0xbfffe7e8, h_errnop=0xbfffe7f4) at ../nss/getXXbyYY_r.c:266 > #10 0xb72d8685 in gethostid () at ../sysdeps/unix/sysv/linux/ > gethostid.c:104 > #11 0xb7b647d4 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003 > #12 0xb7b7f20a in uhd::usrprio_rpc::usrprio_rpc_ > client::usrprio_rpc_client(std::string, std::string) () from > /usr/lib/i386-linux-gnu/libuhd.so.003 > #13 0xb7b835c4 in uhd::niusrprio::niusrprio_session::enumerate(std::string > const&, std::vector<uhd::usrprio_rpc::usrprio_device_info, > std::allocator<uhd::usrprio_rpc::usrprio_device_info> >&) () from > /usr/lib/i386-linux-gnu/libuhd.so.003 > #14 0xb7a73d98 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003 > #15 0xb799f7f9 in ?? () from /usr/lib/i386-linux-gnu/libuhd.so.003 > #16 0xb7bf68c4 in uhd::device::find(uhd::device_addr_t const&, > uhd::device::device_filter_t) () from /usr/lib/i386-linux-gnu/ > libuhd.so.003 > #17 0x0806ed69 in uhd_device::open (this=0x80f5cd0, args="", extref=false) > at UHDDevice.cpp:537 > #18 0x0805586f in main (argc=1, argv=0xbffff7f4) at runTransceiver.cpp:158 > > > On Tue, Nov 29, 2016 at 12:55 PM, Nikos Balkanas <nba...@gm...> > wrote: > >> Hi tyrus, >> >> If you type: >> gdb> where >> to gdb prompt, at SIGSEGV, it should tell you the call stack...if you >> have compiled with -g flag... >> >> >> On Tue, Nov 29, 2016 at 11:43 AM, ty <tyr...@gm...> wrote: >> >>> In addition, I ran a gdb against the transceiver and this was the >>> output. Seems to point to a library >>> >>> (gdb) set auto-load safe-path / >>> (gdb) run >>> Starting program: /OpenBTS/transceiver >>> >>> Program received signal SIGTERM, Terminated. >>> 0xb7fdf0d0 in _start () from /lib/ld-linux.so.2 >>> (gdb) >>> >>> >>> On Tue, Nov 29, 2016 at 12:35 PM, ty <tyr...@gm...> wrote: >>> >>>> Hi Tom, >>>> >>>> I did a 'make clean' and 'make' for the transceiver but the error >>>> persists. Any further leads? >>>> >>>> Niko. >>>> >>>> I am running UHD_003.010.001.000-release from the Ettus Repo. >>>> >>>> Thank you >>>> >>>> On Tue, Nov 29, 2016 at 11:50 AM, Nikos Balkanas <nba...@gm...> >>>> wrote: >>>> >>>>> UHD was indeed changed recently incorporating rfnoc code into its >>>>> mainbranch. >>>>> What is your UHD version? >>>>> >>>>> BR, >>>>> Nikos >>>>> >>>>> >>>>> >>>>> On Tue, Nov 29, 2016 at 10:08 AM, Tom Tsou <to...@ts...> wrote: >>>>> >>>>>> On Mon, Nov 28, 2016 at 6:46 AM, ty <tyr...@gm...> wrote: >>>>>> > >>>>>> > *** Error in `./transceiver': free(): invalid pointer: 0x083cda64 >>>>>> *** >>>>>> > >>>>>> > It simply terminates with no further information. What could be the >>>>>> problem? >>>>>> > My USRP is detectable through uhd_usrp_probe. >>>>>> >>>>>> Could be an ABI issue if there was a recent UHD version change. Try >>>>>> rebuilding the transceiver with 'make clean' followed by 'make'. >>>>>> >>>>>> -TT >>>>>> >>>>>> ------------------------------------------------------------ >>>>>> ------------------ >>>>>> _______________________________________________ >>>>>> Openbts-discuss mailing list >>>>>> Ope...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >>>>>> >>>>> >>>>> >>>> >>> >> > |