[srslte-users] Segmentation fault during LTE-UE Prach procedure
Liqun Liu
lliu at w2bi.com
Wed Oct 11 16:37:45 UTC 2017
Ismael
I verified that the segmentation fault issue has been fixed. The enodeB is Radisys tnb 5.0 runs on Intel T3300 hardware.
Thanks for sharing the excellent SW with community.
Liqun
From: Ismael Gomez [mailto:ismael.gomez at softwareradiosystems.com]
Sent: Wednesday, October 11, 2017 11:13 AM
To: Liqun Liu <lliu at w2bi.com>; Andre Puschmann <andre.puschmann at softwareradiosystems.com>; srslte-users at lists.softwareradiosystems.com
Subject: Re: [srslte-users] Segmentation fault during LTE-UE Prach procedure
Hi again.
I think we've been able to fix the issue. It is an overflow of the msg3_buffer. We've never seen an eNodeB requesting such large Msg3 and our buffer was statically allocated to something much smaller. We've added a check and increased the buffer so hopefully shouldn't happen again in the future. Can you let us know what eNodeB brand and model you are using? Would be very useful for our records.
I've created a branch called fix_issue_103 in the repository in github. When you got a chance, we'd appreciate if you test it again and let us know how it works. I've opened an issue on github (https://github.com/srsLTE/srsLTE/issues/103) in case you want to reply directly there.
Thank a lot for helping us to identify this bug.
Regards
Ismael
On Tue, 10 Oct 2017 at 17:37 Liqun Liu <lliu at w2bi.com<mailto:lliu at w2bi.com>> wrote:
Ismael
This the the log in stdout.
11:35:05.262073 [PHY0] Debug [05599] SYNC: state=5
11:35:05.262114 [PHY1] Debug [05599] TTI 5599 running
11:35:05.262153 [PHY0] Debug [05599] tti=5599, dl_rnti_start=-1, dl_rnti_end=-1, dl_rnti=0x0
11:35:05.262203 [MAC ] Info [05600] RA: PDCCH: seq=1, ra-rnti=0x4, ra-tti=5603
Random Access Transmission: seq=1, ra-rnti=0x4
11:35:05.262219 [PHY0] Debug [05599] Set DL rnti: start=5606, end=5616, value=0x4
11:35:05.262352 [PHY0] Debug [05600] SYNC: Worker 0 synchronized
11:35:05.262379 [PHY0] Debug [05600] SYNC: Setting TTI=5600, tx_mutex=6 to worker 0
11:35:05.262387 [PHY0] Debug [05600] SYNC: state=5
11:35:05.262393 [PHY0] Debug [05600] TTI 5600 running
11:35:05.262406 [PHY0] Debug [05600] tti=5600, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.263187 [PHY0] Debug [05601] SYNC: Worker 1 synchronized
11:35:05.263213 [PHY0] Debug [05601] SYNC: Setting TTI=5601, tx_mutex=7 to worker 1
11:35:05.263238 [PHY0] Debug [05601] SYNC: state=5
11:35:05.263267 [PHY1] Debug [05601] TTI 5601 running
11:35:05.263288 [PHY0] Debug [05601] tti=5601, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.264256 [PHY0] Debug [05602] SYNC: Worker 0 synchronized
11:35:05.264303 [PHY0] Debug [05602] SYNC: Setting TTI=5602, tx_mutex=0 to worker 0
11:35:05.264311 [PHY0] Debug [05602] SYNC: state=5
11:35:05.264334 [PHY0] Debug [05602] TTI 5602 running
11:35:05.264349 [PHY0] Debug [05602] tti=5602, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.265291 [PHY0] Debug [05603] SYNC: Worker 1 synchronized
11:35:05.265304 [PHY0] Debug [05603] SYNC: Setting TTI=5603, tx_mutex=1 to worker 1
11:35:05.265310 [PHY0] Debug [05603] SYNC: state=5
11:35:05.265344 [PHY1] Debug [05603] TTI 5603 running
11:35:05.265361 [PHY0] Debug [05603] tti=5603, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.266175 [PHY0] Debug [05604] SYNC: Worker 0 synchronized
11:35:05.266182 [PHY0] Debug [05604] SYNC: Setting TTI=5604, tx_mutex=2 to worker 0
11:35:05.266187 [PHY0] Debug [05604] SYNC: state=5
11:35:05.266190 [PHY0] Debug [05604] TTI 5604 running
11:35:05.266199 [PHY0] Debug [05604] tti=5604, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.267285 [PHY0] Debug [05605] SYNC: Worker 1 synchronized
11:35:05.267292 [PHY0] Debug [05605] SYNC: Setting TTI=5605, tx_mutex=3 to worker 1
11:35:05.267311 [PHY0] Debug [05605] SYNC: state=5
11:35:05.267344 [PHY1] Debug [05605] TTI 5605 running
11:35:05.267359 [PHY0] Debug [05605] tti=5605, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.268132 [PHY0] Debug [05606] SYNC: Worker 0 synchronized
11:35:05.268143 [PHY0] Debug [05606] SYNC: Setting TTI=5606, tx_mutex=4 to worker 0
11:35:05.268149 [PHY0] Debug [05606] SYNC: state=5
11:35:05.268151 [PHY0] Debug [05606] TTI 5606 running
11:35:05.268159 [PHY0] Debug [05606] tti=5606, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.268332 [PHY0] Debug [05606] tti=5606, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.268339 [PHY0] Debug [05606] Looking for RNTI=0x4
11:35:05.268369 [PHY0] Debug [05606] SYNC: Sending in-sync to RRC
11:35:05.269198 [PHY0] Debug [05607] SYNC: Worker 1 synchronized
11:35:05.269205 [PHY0] Debug [05607] SYNC: Setting TTI=5607, tx_mutex=5 to worker 1
11:35:05.269224 [PHY0] Debug [05607] SYNC: state=5
11:35:05.269256 [PHY1] Debug [05607] TTI 5607 running
11:35:05.269271 [PHY0] Debug [05607] tti=5607, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.269424 [PHY0] Debug [05607] tti=5607, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.269430 [PHY1] Debug [05607] Looking for RNTI=0x4
11:35:05.269447 [PHY1] Debug [05607] SYNC: Sending in-sync to RRC
11:35:05.270267 [PHY0] Debug [05608] SYNC: Worker 0 synchronized
11:35:05.270274 [PHY0] Debug [05608] SYNC: Setting TTI=5608, tx_mutex=6 to worker 0
11:35:05.270279 [PHY0] Debug [05608] SYNC: state=5
11:35:05.270282 [PHY0] Debug [05608] TTI 5608 running
11:35:05.270290 [PHY0] Debug [05608] tti=5608, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.270451 [PHY0] Debug [05608] tti=5608, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.270458 [PHY0] Debug [05608] Looking for RNTI=0x4
11:35:05.270472 [PHY0] Debug [05608] SYNC: Sending in-sync to RRC
11:35:05.271163 [PHY0] Debug [05609] SYNC: Worker 1 synchronized
11:35:05.271170 [PHY0] Debug [05609] SYNC: Setting TTI=5609, tx_mutex=7 to worker 1
11:35:05.271176 [PHY0] Debug [05609] SYNC: state=5
11:35:05.271222 [PHY1] Debug [05609] TTI 5609 running
11:35:05.271236 [PHY0] Debug [05609] tti=5609, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.271397 [PHY0] Debug [05609] tti=5609, dl_rnti_start=5606, dl_rnti_end=5616, dl_rnti=0x4
11:35:05.271403 [PHY1] Debug [05609] Looking for RNTI=0x4
11:35:05.271456 [PHY1] Info [05609] PDCCH: DL DCI Format1A cce_index= 0, L=8, n_data_bits=27, hex=[80 00 48 00 ]
11:35:05.271461 [MAC ] Debug [05609] RA: Rx: DL grant found RA-RNTI=4
11:35:05.271472 [PHY1] Debug [05609] DL Buffer TTI 5609: Decoding PDSCH
11:35:05.271538 [PHY1] Info [05609] PDSCH: l_crb= 1, harq=1, snr=24.9 dB, TB0: tbs=7, mcs=0, rv=0, crc=OK, it=1, dec_time= 55 us
11:35:05.271544 [PHY1] Debug [05609] dl_ack={1, 0}, generate_ack=0
11:35:05.271552 [MAC ] Debug [05609] RA: Rx: RAR decoded successfully TBS=7
11:35:05.271562 [PHY0] Info [05609] PHY: Set TA RAR: ta_cmd: 4, n_ta: 64, ta_usec: 2.1
11:35:05.271569 [MAC ] Debug [05610] Applying RAR TA CMD 4
11:35:05.271574 [PHY0] Debug [05609] Set DL rnti: start=-1, end=-1, value=0x0
11:35:05.271579 [MAC ] Info [05610] RA: Rx: RAPID=1, TA=4
11:35:05.271583 [PHY0] Debug [05609] Set DL rnti: start=-1, end=-1, value=0x45
11:35:05.271587 [MAC ] Debug [05610] RA: Rx: Going to Contention Resolution state
11:35:05.271601 [PHY1] Debug [05609] SYNC: Sending in-sync to RRC
11:35:05.272247 [PHY0] Debug [05610] SYNC: Worker 0 synchronized
11:35:05.272254 [PHY0] Debug [05610] SYNC: Setting TTI=5610, tx_mutex=0 to worker 0
11:35:05.272260 [PHY0] Debug [05610] SYNC: state=5
11:35:05.272262 [PHY0] Debug [05610] TTI 5610 running
11:35:05.272271 [PHY0] Debug [05610] tti=5610, dl_rnti_start=-1, dl_rnti_end=-1, dl_rnti=0x45
11:35:05.272429 [PHY0] Debug [05610] tti=5610, dl_rnti_start=-1, dl_rnti_end=-1, dl_rnti=0x45
11:35:05.272436 [PHY0] Debug [05610] Looking for RNTI=0x45
11:35:05.272470 [PHY0] Debug [05610] SYNC: Sending in-sync to RRC
11:35:05.272507 [MAC ] Debug [05611] RA: ConRes: Msg3 not yet transmitted
11:35:05.273292 [PHY0] Debug [05611] SYNC: Worker 1 synchronized
11:35:05.273299 [PHY0] Debug [05611] SYNC: Setting TTI=5611, tx_mutex=1 to worker 1
11:35:05.273304 [PHY0] Debug [05611] SYNC: state=5
11:35:05.273351 [PHY1] Debug [05611] TTI 5611 running
11:35:05.273366 [PHY0] Debug [05611] tti=5611, dl_rnti_start=-1, dl_rnti_end=-1, dl_rnti=0x45
11:35:05.273496 [PHY0] Debug [05611] tti=5611, dl_rnti_start=-1, dl_rnti_end=-1, dl_rnti=0x45
11:35:05.273503 [PHY1] Debug [05611] Looking for RNTI=0x45
11:35:05.273562 [PHY1] Debug [05611] RAR grant found for TTI=5611
11:35:05.273567 [MAC ] Debug [05611] Getting Msg3 buffer payload, grant size=117 bytes
11:35:05.273575 [RLC ] Info SRB0 Complete SDU scheduled for tx. Stack latency: 968690 us
11:35:05.273595 [RLC ] Info TX SRB0, Transparent Mode PDU
0000: 50 00 00 00 3e 86
11:35:05.273603 [MAC ] Info [05611] SDU: allocated lcid=0, rlc_buffer=6, allocated=6/116, max_sdu_sz=-1, remaining=110
11:35:05.273609 [MAC ] Debug [05611] BSR: Including Regular BSR: grant_size=110, total_data=11, bsr_sz=1
11:35:05.273614 [MAC ] Debug [05611] Assembled MAC PDU msg size 9/117 bytes
11:35:05.273620 [MAC ] Debug [05611] Wrote PDU: pdu_len=0, header_and_ce=5 (4+1), nof_subh=2, last_sdu=0, sdu_len=6, onepad=0, multi=0
------------------------------
Segmentation fault
Thanks,
Liqun
________________________________
From: Ismael Gomez <ismael.gomez at softwareradiosystems.com<mailto:ismael.gomez at softwareradiosystems.com>>
Sent: Tuesday, October 10, 2017 11:31:00 AM
To: Liqun Liu; Andre Puschmann; srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
Subject: Re: [srslte-users] Segmentation fault during LTE-UE Prach procedure
If you believe the logs are being interrupted earlier due to the segfault (most likely) you can redirect them to stdout by setting filename = stdout in [log] section in ue.conf. Also, I was just thinking that you should disable AGC. It's not working properly and only required if you are very far from the cell. Just set rx_gain=40 (or 50) ue.conf and should work for most typical conditions.
thanks
On Tue, 10 Oct 2017 at 17:29 Ismael Gomez <ismael.gomez at softwareradiosystems.com<mailto:ismael.gomez at softwareradiosystems.com>> wrote:
Please send the ue.log and output console to the list and we'll try to see what happens.
thanks
On Tue, 10 Oct 2017 at 17:27 Liqun Liu <lliu at w2bi.com<mailto:lliu at w2bi.com>> wrote:
Ismael,
I tried the latest code in github today. the UE attempted attach without any plmn hard coding .
But, the segmentation still there on the same line of code (srsLTE/lib/src/common/pdu.cc:463).
Also, the RX AGC (comment RX gain in configure file) behave different in the new code base than version 2.
In, version 2.0, AGC works fine. but in new release, UE detected the cell but not go forward. It feels UE is in a dead loop.
we are ruing a commercial grade femto enb in our lab, so that we know the USIM security settings. Regular UEs work with enb without issue. we used
imsi = 311480012345678
imei = 353490069873319
Liqun
________________________________
From: Ismael Gomez <ismael.gomez at softwareradiosystems.com<mailto:ismael.gomez at softwareradiosystems.com>>
Sent: Saturday, October 7, 2017 4:21:42 PM
To: Liqun Liu; Andre Puschmann; srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
Subject: Re: [srslte-users] Segmentation fault during LTE-UE Prach procedure
Hi Liqun,
We've committed a hot-fix just today. I think the problem could be caused by not attaching a roaming PLMN. Can you try again please?
Are you trying to attach to a commercial network? How have you configured the USIM settings?
Regards
Ismael
On Fri, 6 Oct 2017 at 21:24 Liqun Liu <lliu at w2bi.com<mailto:lliu at w2bi.com>> wrote:
Andre,
I have all layers set to debug. But around line 200, log start to repeat itself.
Thanks,
Liqun
-----Original Message-----
From: Andre Puschmann [mailto:andre.puschmann at softwareradiosystems.com<mailto:andre.puschmann at softwareradiosystems.com>]
Sent: Friday, October 06, 2017 3:03 PM
To: Liqun Liu <lliu at w2bi.com<mailto:lliu at w2bi.com>>; srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
Subject: Re: [srslte-users] Segmentation fault during LTE-UE Prach procedure
Hey,
can you attach logs with PHY level set to info please.
Thanks
Andre
On 06/10/17 20:39, Liqun Liu wrote:
> Ismael,
>
>
>
> I tried the 17-09 version of lteue and get different result.
>
> In the older version, lteue will try to prach and get segmentation fault.
>
> In the 17-09 version, lteue
>
>
>
> Fount cell: PCI=19, PRB=50, Ports=2, CFO=-1.4 Khz
>
> Fount PLMN: Id=311480, TAC=1
>
>
>
>
>
> Log also shows lteue get mib and sib1. But it just go to the cell
> search loop again and never try to do the PRACH procedure.
>
>
>
> Liqun
>
>
>
> *From:*Liqun Liu
> *Sent:* Wednesday, October 04, 2017 9:55 AM
> *To:* Ismael Gomez <ismael.gomez at softwareradiosystems.com<mailto:ismael.gomez at softwareradiosystems.com>>;
> srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
> *Subject:* Re: [srslte-users] Segmentation fault during LTE-UE Prach
> procedure
>
>
>
> Ismael,
>
>
>
> Sure. looking forward to test the new release.
>
> To add some background of test,
>
>
>
> LTE-UE attached to the Amarisoft enb. but crashed on a commercial eNB.
>
>
>
> Thanks,
>
>
>
> Liqun
>
> ----------------------------------------------------------------------
> --
>
> *From:*Ismael Gomez <ismael.gomez at softwareradiosystems.com<mailto:ismael.gomez at softwareradiosystems.com>
> <mailto:ismael.gomez at softwareradiosystems.com<mailto:ismael.gomez at softwareradiosystems.com>>>
> *Sent:* Wednesday, October 4, 2017 6:19:02 AM
> *To:* Liqun Liu; srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
> <mailto:srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>>
> *Subject:* Re: [srslte-users] Segmentation fault during LTE-UE Prach
> procedure
>
>
>
> Hi Li,
>
>
>
> We are going to release a new version this Friday. Probably the best
> is to wait and see if the bug is still present with that new version.
>
>
>
> Thanks
>
>
>
> On Tue, 3 Oct 2017 at 23:00 Liqun Liu <lliu at w2bi.com<mailto:lliu at w2bi.com>
> <mailto:lliu at w2bi.com<mailto:lliu at w2bi.com>>> wrote:
>
> Hi all,
>
>
>
> I experience this segmentation fault issue when lte-UE try to PRACH.
> It looks likely the subheaders of pdu_msg was not initialized
> properly. I went through archive and do not see anyone else has
> similar issue. Can someone give some help?
>
>
>
>
>
> I attached the gdb log below
>
>
>
> Searching for cell...
> Using Volk machine: avx2_64_mmx_orc
> Found CELL ID: 19 CP: Normal , CFO: -0.6 KHz.
> Trying to decode MIB...
> - Cell ID: 19
> - Nof ports: 2
> - CP: Normal
> - PRB: 50
> - PHICH Length: Normal
> - PHICH Resources: 1/6
> - SFN: 0
> MIB received BW=10 MHz
> [New Thread 0x7fffc37fe700 (LWP 17177)]
> Initializating cell configuration...
> -- Asking for clock rate 23.040000 MHz...
> -- Actually got clock rate 23.040000 MHz.
> -- Performing timer loopback test... pass
> Setting Sampling frequency 11.52 MHz
> Setting TX/RX offset 120 samples, 10.42 us
> SIB1 received, CellID=19, PLMN Id: MCC 311 MNC 480
> SIB2 received
> [Thread 0x7fffc37fe700 (LWP 17177) exited]
> Random Access Transmission: seq=1, ra-rnti=0x4
>
> ------------------------------
>
> Thread 24 "srsue_debug" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffd97fa700 (LWP 17157)]
> 0x000000000050091e in srslte::sch_subh::get_payload_size (this=0x0)
> at /home/w2bi/CLionProjects/srsLTE/lib/src/common/pdu.cc:459
> 459 return nof_bytes;
> (gdb) backtrace
> #0 0x000000000050091e in srslte::sch_subh::get_payload_size
> (this=0x0) at /home/w2bi/CLionProjects/srsLTE/lib/src/common/pdu.cc:459
> #1 0x00000000004ffe7b in srslte::sch_pdu::write_packet
> (this=0x7ffff1a5f708, log_h=0x7ffff1abf5e0) at
> /home/w2bi/CLionProjects/srsLTE/lib/src/common/pdu.cc:229
> #2 0x00000000004c9567 in srsue::mux::pdu_get (this=0x7ffff1a5f618,
> payload=0x7ffff1a5f682 "", pdu_sz=117, tx_tti=0, pid=0) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/mux.cc:253
> #3 0x00000000004c9db8 in srsue::mux::msg3_get (this=0x7ffff1a5f618,
> payload=0x4c93800 "", pdu_sz=117) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/mux.cc:348
> #4 0x00000000004d43ee in
> srsue::ul_harq_entity::ul_harq_process::run_tti
> (this=0x7ffff1a60bf8, tti_tx=1945, grant=0x7fffd97f9720,
> action=0x7fffd97f9c40)
> at /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/ul_harq.cc:250
> #5 0x00000000004d3c0e in srsue::ul_harq_entity::run_tti
> (this=0x7ffff1a60a68, tti=1941, grant=0x7fffd97f9720,
> action=0x7fffd97f9c40) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/ul_harq.cc:143
> #6 0x00000000004d39ba in srsue::ul_harq_entity::new_grant_ul
> (this=0x7ffff1a60a68, grant=..., action=0x7fffd97f9c40) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/ul_harq.cc:119
> #7 0x00000000004c6bf2 in srsue::mac::new_grant_ul
> (this=0x7ffff1a5f4a8, grant=..., action=0x7fffd97f9c40) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/mac.cc:316
> #8 0x00000000004d81e9 in srsue::phch_worker::work_imp
> (this=0x7ffff7f1b010) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/phy/phch_worker.cc:247
> #9 0x00000000005054bb in srslte::thread_pool::worker::run_thread
> (this=0x7ffff7f1b010) at
> /home/w2bi/CLionProjects/srsLTE/lib/src/common/thread_pool.cc:61
> #10 0x00000000004c7f28 in thread::thread_function_entry
> (_this=0x7ffff7f1b010) at
> /home/w2bi/CLionProjects/srsLTE/lib/include/srslte/common/threads.h:73
> #11 0x00007ffff7bc16ba in start_thread (arg=0x7fffd97fa700) at
> pthread_create.c:333
> #12 0x00007ffff61273dd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> (gdb) frame 0
> #0 0x000000000050091e in srslte::sch_subh::get_payload_size
> (this=0x0) at /home/w2bi/CLionProjects/srsLTE/lib/src/common/pdu.cc:459
> 459 return nof_bytes;
> (gdb) print this
> $1 = (srslte::sch_subh * const) 0x0
> (gdb) frame 1
> #1 0x00000000004ffe7b in srslte::sch_pdu::write_packet
> (this=0x7ffff1a5f708, log_h=0x7ffff1abf5e0) at
> /home/w2bi/CLionProjects/srsLTE/lib/src/common/pdu.cc:229
> 229 printf("SUBH %d is_sdu=%d, payload=%d\n", i,
> subheaders[i].is_sdu(), subheaders[i].get_payload_size());
> (gdb) print i
> $2 = 0
> (gdb) print subheaders[0]
> Cannot access memory at address 0x0
> (gdb) print subheaders
> $3 = std::vector of length 0, capacity 0
>
>
>
> comment out /srsLTE/lib/src/common/pdu.cc:459 \, run again and get
> similar error
>
>
>
> Searching for cell...
> Using Volk machine: avx2_64_mmx_orc
> Found CELL ID: 19 CP: Normal , CFO: -0.7 KHz.
> Trying to decode MIB...
> - Cell ID: 19
> - Nof ports: 2
> - CP: Normal
> - PRB: 50
> - PHICH Length: Normal
> - PHICH Resources: 1/6
> - SFN: 0
> MIB received BW=10 MHz
> [New Thread 0x7fffc37fe700 (LWP 3125)]
> Initializating cell configuration...
> -- Asking for clock rate 23.040000 MHz...
> -- Actually got clock rate 23.040000 MHz.
> -- Performing timer loopback test... pass
> Setting Sampling frequency 11.52 MHz
> Setting TX/RX offset 120 samples, 10.42 us
> SIB1 received, CellID=19, PLMN Id: MCC 311 MNC 480
> SIB2 received
> [Thread 0x7fffc37fe700 (LWP 3125) exited]
> Random Access Transmission: seq=1, ra-rnti=0x9
>
> ------------------------------
> Random Access Transmission: seq=2, ra-rnti=0x4
>
> Thread 26 "srsue_debug_rad" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffcbfff700 (LWP 3106)]
> 0x00000000004c3539 in srslte::pdu<srslte::sch_subh>::init_
> (this=0x7ffff1a5f708, buffer_tx_ptr=0x7ffff1a5f682 "",
> pdu_len_bytes=117, is_ulsch=true)
> at
> /home/w2bi/CLionProjects/srsLTE/lib/include/srslte/common/pdu.h:173
> 173 subheaders[i].parent = this;
> (gdb) backtrace
> #0 0x00000000004c3539 in srslte::pdu<srslte::sch_subh>::init_
> (this=0x7ffff1a5f708, buffer_tx_ptr=0x7ffff1a5f682 "",
> pdu_len_bytes=117, is_ulsch=true)
> at
> /home/w2bi/CLionProjects/srsLTE/lib/include/srslte/common/pdu.h:173
> #1 0x00000000004ca1e3 in srslte::pdu<srslte::sch_subh>::init_tx
> (this=0x7ffff1a5f708, payload=0x7ffff1a5f682 "", pdu_len_bytes=117,
> is_ulsch=true)
> at
> /home/w2bi/CLionProjects/srsLTE/lib/include/srslte/common/pdu.h:78
> #2 0x00000000004c8d11 in srsue::mux::pdu_get (this=0x7ffff1a5f618,
> payload=0x7ffff1a5f682 "", pdu_sz=117, tx_tti=0, pid=0) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/mux.cc:167
> #3 0x00000000004c9db8 in srsue::mux::msg3_get (this=0x7ffff1a5f618,
> payload=0x4c90500 "", pdu_sz=117) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/mux.cc:348
> #4 0x00000000004d43ee in
> srsue::ul_harq_entity::ul_harq_process::run_tti
> (this=0x7ffff1a60bf8, tti_tx=3905, grant=0x7fffcbffe720,
> action=0x7fffcbffec40)
> at /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/ul_harq.cc:250
> #5 0x00000000004d3c0e in srsue::ul_harq_entity::run_tti
> (this=0x7ffff1a60a68, tti=3901, grant=0x7fffcbffe720,
> action=0x7fffcbffec40) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/ul_harq.cc:143
> #6 0x00000000004d39ba in srsue::ul_harq_entity::new_grant_ul
> (this=0x7ffff1a60a68, grant=..., action=0x7fffcbffec40) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/ul_harq.cc:119
> #7 0x00000000004c6bf2 in srsue::mac::new_grant_ul
> (this=0x7ffff1a5f4a8, grant=..., action=0x7fffcbffec40) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/mac/mac.cc:316
> #8 0x00000000004d81e9 in srsue::phch_worker::work_imp
> (this=0x7ffff7f3aa98) at
> /home/w2bi/CLionProjects/srsLTE/srsue/src/phy/phch_worker.cc:247
> #9 0x0000000000505211 in srslte::thread_pool::worker::run_thread
> (this=0x7ffff7f3aa98) at
> /home/w2bi/CLionProjects/srsLTE/lib/src/common/thread_pool.cc:61
> #10 0x00000000004c7f28 in thread::thread_function_entry
> (_this=0x7ffff7f3aa98) at
> /home/w2bi/CLionProjects/srsLTE/lib/include/srslte/common/threads.h:73
> #11 0x00007ffff7bc16ba in start_thread (arg=0x7fffcbfff700) at
> pthread_create.c:333
> #12 0x00007ffff61273dd in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> (gdb) frame 0
> #0 0x00000000004c3539 in srslte::pdu<srslte::sch_subh>::init_
> (this=0x7ffff1a5f708, buffer_tx_ptr=0x7ffff1a5f682 "",
> pdu_len_bytes=117, is_ulsch=true)
> at
> /home/w2bi/CLionProjects/srsLTE/lib/include/srslte/common/pdu.h:173
> 173 subheaders[i].parent = this;
> (gdb) print i
> $1 = 0
> (gdb) print subheaders
> $2 = std::vector of length 0, capacity 0
> (gdb) frame 1
> #1 0x00000000004ca1e3 in srslte::pdu<srslte::sch_subh>::init_tx
> (this=0x7ffff1a5f708, payload=0x7ffff1a5f682 "", pdu_len_bytes=117,
> is_ulsch=true)
> at
> /home/w2bi/CLionProjects/srsLTE/lib/include/srslte/common/pdu.h:78
> 78 init_(payload, pdu_len_bytes, is_ulsch);
>
> thanks,
>
>
>
> Liqun
>
>
>
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
> <mailto:srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>>
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
>
>
> _______________________________________________
> srslte-users mailing list
> srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>
_______________________________________________
srslte-users mailing list
srslte-users at lists.softwareradiosystems.com<mailto:srslte-users at lists.softwareradiosystems.com>
http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20171011/951ec3d3/attachment.htm>
More information about the srsran-users
mailing list