Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Find/Track states in sync_t object #1

Closed
ismagom opened this issue Jan 30, 2014 · 0 comments
Closed

Find/Track states in sync_t object #1

ismagom opened this issue Jan 30, 2014 · 0 comments
Assignees
@ismagom
Labels
enhancement
Milestone
v0.0.1: Cell Search

Comments

@ismagom
Copy link
Collaborator

ismagom commented Jan 30, 2014

During Track state, convolution only around expected peak.
@ghost ghost assigned ismagom Jan 30, 2014
@ismagom ismagom closed this as completed Feb 3, 2014
suttonpd added a commit that referenced this issue Apr 15, 2014
@suttonpd
Merge pull request #1 from ismagom/master
3e53272 
Updating suttonpd fork
ismagom pushed a commit that referenced this issue Jun 6, 2014
Merge pull request #1 from trondeau/uhd_mods
b91082d 
UHD mods
@HughAndersonNUS HughAndersonNUS mentioned this issue Apr 7, 2017
Closed
suttonpd pushed a commit that referenced this issue May 9, 2017
@ismagom
Merge pull request #1 from softwareradiosystems/next_lime
a723b79 
adding native lime, soapy, decimation filtering and neon optimizations
aleksander0m added a commit to aleksander0m/srsLTE that referenced this issue Nov 14, 2019
@aleksander0m
enb,s1ap: fix segfault when disconnected from MME
0d0d470 
If recv() fails and returns -1, we should not treat that as a received
PDU in any case, or we'll end up with N_bytes being 0xFFFFFFFF after
casting -1 as an unsigned integer.

So, if we detect disconnection and we successfully reconnect, fallback
to running recv() again right away.

    Thread 37 "S1AP" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7fff9c879700 (LWP 11443)]
    0x000000000081d669 in liblte_value_2_bits (value=160, bits=0x7fff9c73ec30, N_bits=8) at /home/aleksander/srsLTE/lib/src/asn1/liblte_common.cc:64
    64	    (*bits)[i] = (value >> (N_bits - i - 1)) & 0x1;
    (gdb) bt
    #0  0x000000000081d669 in liblte_value_2_bits (value=160, bits=0x7fff9c73ec30, N_bits=8) at /home/aleksander/srsLTE/lib/src/asn1/liblte_common.cc:64
    srsran#1  0x000000000081d831 in liblte_unpack (bytes=0x148c7c80, bits=0x7fff9c73ec80) at /home/aleksander/srsLTE/lib/src/asn1/liblte_common.cc:118
    srsran#2  0x000000000087dee3 in liblte_s1ap_unpack_s1ap_pdu (msg=0x148c7c80, s1ap_pdu=0x7fff9c757f50) at /home/aleksander/srsLTE/lib/src/asn1/liblte_s1ap.cc:40300
    srsran#3  0x0000000000000000 in ?? ()

    (gdb) fr 2
    srsran#2  0x000000000087dee3 in liblte_s1ap_unpack_s1ap_pdu (msg=0x148c7c80, s1ap_pdu=0x7fff9c757f50) at /home/aleksander/srsLTE/lib/src/asn1/liblte_s1ap.cc:40300
    40300	    liblte_unpack(msg, &bit_msg);

    (gdb) p *msg
    $22 = {N_bytes = 4294967295, header = '\000' <repeats 1019 times>, msg = '\000' <repeats 12240 times>...}
aleksander0m added a commit to aleksander0m/srsLTE that referenced this issue Nov 14, 2019
@aleksander0m
enb,s1ap: fix segfault when disconnected from MME
685efa1 
If recv() fails and returns -1, we should not treat that as a received
PDU in any case, or we'll end up with N_bytes being 0xFFFFFFFF after
casting -1 as an unsigned integer.

So, if we detect disconnection and we successfully reconnect, fallback
to running recv() again right away.

    Thread 37 "S1AP" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7fff9c879700 (LWP 11443)]
    0x000000000081d669 in liblte_value_2_bits (value=160, bits=0x7fff9c73ec30, N_bits=8) at /home/aleksander/srsLTE/lib/src/asn1/liblte_common.cc:64
    64	    (*bits)[i] = (value >> (N_bits - i - 1)) & 0x1;
    (gdb) bt
    #0  0x000000000081d669 in liblte_value_2_bits (value=160, bits=0x7fff9c73ec30, N_bits=8) at /home/aleksander/srsLTE/lib/src/asn1/liblte_common.cc:64
    srsran#1  0x000000000081d831 in liblte_unpack (bytes=0x148c7c80, bits=0x7fff9c73ec80) at /home/aleksander/srsLTE/lib/src/asn1/liblte_common.cc:118
    srsran#2  0x000000000087dee3 in liblte_s1ap_unpack_s1ap_pdu (msg=0x148c7c80, s1ap_pdu=0x7fff9c757f50) at /home/aleksander/srsLTE/lib/src/asn1/liblte_s1ap.cc:40300
    srsran#3  0x0000000000000000 in ?? ()

    (gdb) fr 2
    srsran#2  0x000000000087dee3 in liblte_s1ap_unpack_s1ap_pdu (msg=0x148c7c80, s1ap_pdu=0x7fff9c757f50) at /home/aleksander/srsLTE/lib/src/asn1/liblte_s1ap.cc:40300
    40300	    liblte_unpack(msg, &bit_msg);

    (gdb) p *msg
    $22 = {N_bytes = 4294967295, header = '\000' <repeats 1019 times>, msg = '\000' <repeats 12240 times>...}
@shodan007 shodan007 mentioned this issue May 30, 2020
Closed
@VitalyGrankin VitalyGrankin mentioned this issue Sep 7, 2020
Closed
@jin-github1002 jin-github1002 mentioned this issue Sep 20, 2020
Closed
andrepuschmann added a commit that referenced this issue Apr 22, 2021
@andrepuschmann
enb: fix potential invalid access in stdout metrics
eea6f0f 
this fixes a potential access of invalid PHY or MAC metrics by checking
the user entry actually exists.

the RFCI has shown this error:

------DL--------------------------------UL------------------------------------
rnti cqi  ri mcs brate   ok  nok  (%)  snr  phr mcs brate   ok  nok  (%)   bsr
ASAN:DEADLYSIGNAL
=================================================================
m==31838==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x555d482b6893 bp 0x7f6ac32d1160 sp 0x7f6ac32d0bc0 T21)
==31838==The signal is caused by a READ memory access.
==31838==Hint: address points to the zero page.
    #0 0x555d482b6892 in srsenb::metrics_stdout::set_metrics(srsenb::enb_metrics_t const&, unsigned int) /mnt/data/jenkins/workspace/srslte_dev_ogt_zmq_nightly/srsLTE/srsenb/src/metrics_stdout.cc:101
    #1 0x555d482865f1 in srslte::metrics_hub<srsenb::enb_metrics_t>::run_period() /mnt/data/jenkins/workspace/srslte_dev_ogt_zmq_nightly/srsLTE/lib/include/srslte/common/metrics_hub.h:88
    #2 0x555d482865f1 in srslte::periodic_thread::run_thread() /mnt/data/jenkins/workspace/srslte_dev_ogt_zmq_nightly/srsLTE/lib/include/srslte/common/threads.h:143
    #3 0x555d4826813d in srslte::thread::thread_function_entry(void*) /mnt/data/jenkins/workspace/srslte_dev_ogt_zmq_nightly/srsLTE/lib/include/srslte/common/threads.h:102
    #4 0x7f6b0dc546da in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76da)
    #5 0x7f6b0bf0171e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12171e)
andrepuschmann added a commit that referenced this issue Apr 22, 2021
@andrepuschmann
mac: convert rar_pdu_msg[] from vector into array and protect access
732a108 
attempt to address ASAN detected issue:

RACH:  tti=821, cc=3, preamble=11, offset=0, temp_crnti=0x47
ASAN:DEADLYSIGNAL
=================================================================
m==25385==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000024 (pc 0x564b19a26c93 bp 0x7fa0e5f1a8c0 sp 0x7fa0e5f1a798 T8)
==25385==The signal is caused by a WRITE memory access.
==25385==Hint: address points to the zero page.

------DL--------------------------------UL------------------------------------
rnti cqi  ri mcs brate   ok  nok  (%)  snr  phr mcs brate   ok  nok  (%)   bsr
  46 0.10   0 0.0     0    0    0   0%    0  0.0   0     0    0    0   0%   0.0
  47 0.10   0 0.0     0    0    0   0%    0  0.0   0     0    0    0   0%   0.0
    #0 0x564b19a26c92 in srslte::rar_subh::set_ta_cmd(unsigned int) /mnt/data/jenkins/workspace/srslte_ogt_manual_zmq/srsLTE/lib/src/mac/pdu.cc:1136
    #1 0x564b19577f7e in srsenb::mac::assemble_rar(srsenb::sched_interface::dl_sched_rar_grant_t*, unsigned int, int, unsigned int, unsigned int) /mnt/data/jenkins/workspace/srslte_ogt_manual_zmq/srsLTE/srsenb/src/stack/mac/mac.cc:837
    #2 0x564b19591765 in srsenb::mac::get_dl_sched(unsigned int, std::vector<srsenb::mac_interface_phy_lte::dl_sched_t, std::allocator<srsenb::mac_interface_phy_lte::dl_sched_t> >&) /mnt/data/jenkins/workspace/srslte_ogt_manual_zmq/srsLTE/srsenb/src/stack/mac/mac.cc:653
    #3 0x564b19497ee2 in srsenb::lte::sf_worker::work_imp() /mnt/data/jenkins/workspace/srslte_ogt_manual_zmq/srsLTE/srsenb/src/phy/lte/sf_worker.cc:208
    #4 0x564b199f8db4 in
@rriggio rriggio mentioned this issue May 10, 2021
Closed
This was referenced May 14, 2021
Closed
Closed
@shuimoshusheng shuimoshusheng mentioned this issue Jun 18, 2021
Closed
@akhila-rao akhila-rao mentioned this issue Oct 19, 2021
Closed
andrepuschmann added a commit that referenced this issue Oct 21, 2021
@andrepuschmann
mac_nr_test: flush srslog at the end of test
b20fefb 
fixes stack use after free detected by ASAN

2021-08-31T17:21:44.885938 [MAC-NR ] [D] [    0] Building new MAC PDU (9 B)
==10908==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc481b5340 at pc 0x563c0486d489 bp 0x7ffc481b4470 sp 0x7ffc481b4460
READ of size 1 at 0x7ffc481b5340 thread T0
    #0 0x563c0486d488 in srsran::mac_sch_subpdu_nr::to_string(fmt::v7::basic_memory_buffer<char, 500ul, std::allocator<char> >&) (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x139488)
    #1 0x563c0486db87 in srsran::mac_sch_pdu_nr::to_string(fmt::v7::basic_memory_buffer<char, 500ul, std::allocator<char> >&) (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x139b87)
    #2 0x563c0481c127 in srsue::mux_nr::get_pdu(unsigned int) (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0xe8127)
    #3 0x563c0484e62b in srsue::ul_harq_entity_nr::ul_harq_process_nr::new_grant_ul(srsue::mac_interface_phy_nr::mac_nr_grant_ul_t const&, bool const&, srsue::mac_interface_phy_nr::tb_action_ul_t*) (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x11a62b)
    #4 0x563c04850de4 in srsue::ul_harq_entity_nr::new_grant_ul(srsue::mac_interface_phy_nr::mac_nr_grant_ul_t const&, srsue::mac_interface_phy_nr::tb_action_ul_t*) (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x11cde4)
    #5 0x563c047bb004 in srsue::mac_nr::new_grant_ul(unsigned int, srsue::mac_interface_phy_nr::mac_nr_grant_ul_t const&, srsue::mac_interface_phy_nr::tb_action_ul_t*) (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x87004)
    #6 0x563c04760cdc in msg3_test() (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x2ccdc)
    #7 0x563c0475f762 in main (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x2b762)
    #8 0x7fae1cf400b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #9 0x563c047601bd in _start (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x2c1bd)

Address 0x7ffc481b5340 is located in stack of thread T0 at offset 320 in frame
    #0 0x563c0486d78f in srsran::mac_sch_pdu_nr::to_string(fmt::v7::basic_memory_buffer<char, 500ul, std::allocator<char> >&) (/home/ubuntu/workspace/srslte_ubuntu_20.04_pull_request/srslte/build/srsue/src/stack/mac_nr/test/mac_nr_test+0x13978f)
@fpgasdr fpgasdr mentioned this issue Feb 7, 2022
Open
@arfanhayder arfanhayder mentioned this issue Mar 10, 2022
Open
@TallGuy74 TallGuy74 mentioned this issue Jul 6, 2022
Open
@RogerLin88124 RogerLin88124 mentioned this issue Jan 10, 2023
Open
andrepuschmann added a commit that referenced this issue Apr 28, 2023
@andrepuschmann @yagoda
gnb: fix CSI-IM resource information in RRC recnofig for NSA
7251d4d 
amariue was complaining about CSI-IM resources allocated but
not present in resource config.

15:36:05.604 [RRC] -  0002  - DCCH: CellGroupConfig: ERROR: CSI-IM Set resource #0 not found in CSI Resource config #1

the patch simply removes the CSI-IM config.
@Bipro002 Bipro002 mentioned this issue Jun 23, 2023
Open
@sruthi81 sruthi81 mentioned this issue Jun 24, 2023
Closed
@reallsj reallsj mentioned this issue Dec 17, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ismagom ismagom

Labels
enhancement
Projects
None yet
Milestone
v0.0.1: Cell Search
Development

No branches or pull requests
1 participant
@ismagom