[srslte-users] Seg fault in scrambling_b_word

David Rupprecht david.rupprecht at rub.de
Tue Jul 11 14:50:26 UTC 2017


Hello Ismael,

Thanks for providing the patch. Yes, the patch works.

Best Regards,
David

On 11.07.2017 13:19, Ismael Gomez wrote:
> Hey David, 
> 
> Yes you are right. What seems to happen is that the UE receives an UL
> grant while the scrambling sequences are being generated. We never saw
> that before. I've committed a fix, let me know if it works please. We
> can't reproduce the same bug here. 
> 
> Thanks again for your help in identifying the issue. 
> 
> Regards
> Ismael
> 
> 
> 
> On Tue, 11 Jul 2017 at 12:34 David Rupprecht <david.rupprecht at rub.de
> <mailto:david.rupprecht at rub.de>> wrote:
> 
>     Hello,
> 
>     I think I found the issue. It is a race condition. While thread 1 tries
>     to access the not allocated c pointers, thread 2 currently fills the
>     them. The gdb output is attached. That leads me to the question if my pc
>     as not enough resources. That problem did not occur under the
>     srsLTE/srsUE 1.4 version.
> 
>     Best Regards,
>     David
> 
> 
> 
>     On 04.07.2017 12:12, Ismael Gomez wrote:
>     > Hi David,
>     >
>     > So if seq[0] ... seq[4] are non-empty it means that during
>     > srslte_pusch_set_rnti() there was some problem srslte_sequence_pusch()
>     > returned != 0 and it didn't properly initialize. But looking at that
>     > function it is not clear to me how that can happen. Can you insert
>     > breakpoints or print debug messages in those cases to confirm that is
>     > what is happening?
>     >
>     > Thank you
>     >
>     > On Mon, 3 Jul 2017 at 17:41 David Rupprecht
>     <david.rupprecht at rub.de <mailto:david.rupprecht at rub.de>
>     > <mailto:david.rupprecht at rub.de <mailto:david.rupprecht at rub.de>>>
>     wrote:
>     >
>     >     Hello,
>     >
>     >     I just had some time to dig into the problem. It looks like the
>     >     calloc/malloc do not seems to be the problem, because the
>     pointer for
>     >     srslte_pusch_t the seems to be correct allocated. The error occurs
>     >     because the pointer of the seq are not correctly allocated,
>     because c (c
>     >     = 0x0, c_bytes = 0x0, c_float = 0x0, c_short = 0x0) points to
>     an invalid
>     >     address (Interestingly is len=0). Now when using the calloc it
>     points to
>     >     Null as it can be seen below.
>     >
>     >     $9 = {c = 0x7fa2dd4ba000 "", c_bytes = 0x7fa2dd4d2a00
>     >     "^K\026\200\313\353q1\343k\253ݼ\247J\247\263z\367\356V\322蕕~
>     \032<q
>     >     \334,\213~\351a\366\035\214z\267_\243\330\372\350]q\t",
>     >     c_float = 0x7fa2dd4d5c00,
>     >       c_short = 0x7fa2dd538400, len = 100800}
>     >     (gdb) p q->users[27460]->seq[4]
>     >     $10 = {c = 0x7fa2dd569800 "", c_bytes = 0x7fa2dd582200
>     >     ",\351\264\177[\033\207\065\t\301O\256<\240w*\263\"NxPO(",
>     <incomplete
>     >     sequence \337>, c_float = 0x7fa2dd585400, c_short =
>     0x7fa2dd5e7c00, len
>     >     = 100800}
>     >     (gdb) p q->users[27460]->seq[5]
>     >     $11 = {c = 0x0, c_bytes = 0x0, c_float = 0x0, c_short = 0x0,
>     len = 0}
>     >     (gdb) p q->users[27460]->seq[6]
>     >     $12 = {c = 0x0, c_bytes = 0x0, c_float = 0x0, c_short = 0x0,
>     len = 0}
>     >     (gdb) p q->users[27460]->seq[7]
>     >     $13 = {c = 0x0, c_bytes = 0x0, c_float = 0x0, c_short = 0x0,
>     len = 0}
>     >     (gdb) p q->users[27460]->seq[8]
>     >     $14 = {c = 0x0, c_bytes = 0x0, c_float = 0x0, c_short = 0x0,
>     len = 0}
>     >     (gdb) p q->users[27460]->seq[9]
>     >     $15 = {c = 0x0, c_bytes = 0x0, c_float = 0x0, c_short = 0x0,
>     len = 0}
>     >
>     >     The initialization of the struct is done in srslte_pusch_set_rnti.
>     >     The function is called in srslte_ue_ul_set_rnti. One the one
>     hand, if
>     >     srslte_pusch_set_rnti throws an error it is not caught in
>     >     srslte_ue_ul_set_rnti. Or srslte_sequence_init does something
>     wrong, but
>     >     that looks fine for me. Maybe len=0 is also an indicator for
>     the error.
>     >
>     >     Best Regards,
>     >     David
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >     On 30.06.2017 12:41, David Rupprecht wrote:
>     >     > Hello,
>     >     >
>     >     > I have tested the patch a few times and unfortunately the
>     same error
>     >     > continues to occur.
>     >     >
>     >     > Regards,
>     >     > David
>     >     >
>     >     > On 28.06.2017 17:00, David Rupprecht wrote:
>     >     >> Hi,
>     >     >>
>     >     >> thank you for the patch. I will test it. Unfortunately, the
>     error was
>     >     >> not always triggered.
>     >     >>
>     >     >> Regards,
>     >     >> David
>     >     >>
>     >     >> On 28.06.2017 15:03, Ismael Gomez wrote:
>     >     >>> Hi David,
>     >     >>>
>     >     >>> You are completely right. Thanks very much for catching
>     this and
>     >     >>> providing us the exact hints. It was a malloc() that should be
>     >     calloc()
>     >     >>> instead. Apparently in most of the systems malloc() was
>     >     returning zeroed
>     >     >>> memory except in yours :).
>     >     >>>
>     >     >>> I just committed a fix to github. Would be great if you let us
>     >     know if
>     >     >>> it works.
>     >     >>>
>     >     >>> Regards
>     >     >>>
>     >     >>> On Wed, 28 Jun 2017 at 12:20 David Rupprecht
>     >     <david.rupprecht at rub.de <mailto:david.rupprecht at rub.de>
>     <mailto:david.rupprecht at rub.de <mailto:david.rupprecht at rub.de>>
>     >     >>> <mailto:david.rupprecht at rub.de
>     <mailto:david.rupprecht at rub.de> <mailto:david.rupprecht at rub.de
>     <mailto:david.rupprecht at rub.de>>>>
>     >     wrote:
>     >     >>>
>     >     >>>     Hi,
>     >     >>>
>     >     >>>     while running the ue stack I run into a seg fault in the
>     >     function
>     >     >>>     scrambling_b_word. I compiled the ue with debug parameters
>     >     and it looks
>     >     >>>     like the srslte_sequence_t struct is not correctly
>     initiated
>     >     (c=0x5400
>     >     >>>     <error: Cannot access memory at address 0x5400>). The
>     whole
>     >     struct looks
>     >     >>>     like:
>     >     >>>
>     >     >>>     (gdb) p s
>     >     >>>     $8 = (srslte_sequence_t *) 0x7f8eb000b630
>     >     >>>     (gdb) print *s
>     >     >>>     $9 = {c = 0x4800 <error: Cannot access memory at address
>     >     0x4800>,
>     >     >>>     c_bytes = 0x5400 <error: Cannot access memory at address
>     >     0x5400>,
>     >     >>>     c_float = 0x6000, c_short = 0x6c00, len = 30720}
>     >     >>>
>     >     >>>
>     >     >>>     Do you have any suggestions where the problem might be?
>     >     >>>     I attached the gdb output.
>     >     >>>
>     >     >>>     Best Regards,
>     >     >>>     David
>     >     >>>
>     >     >>>     --
>     >     >>>     M.Sc. David Rupprecht
>     >     >>>
>     >     >>>     Ruhr-University Bochum
>     >     >>>     Research Group Information Security
>     >     >>>     Universitätsstraße 150
>     >     >>>     ID 2/130
>     >     >>>     44780 Bochum / Germany
>     >     >>>
>     >     >>>     Phone: +49 234 / 32 - 23508 <tel:+49%20234%203223508>
>     <tel:+49%20234%203223508>
>     >     <tel:+49%20234%203223508>
>     >     >>>     Web: www.infsec.rub.de <http://www.infsec.rub.de>
>     <http://www.infsec.rub.de>
>     >     <http://www.infsec.rub.de>
>     >     >>>     _______________________________________________
>     >     >>>     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>>
>     >     >>>     <mailto: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
>     >     >>>
>     >     >>
>     >     >
>     >
>     >     --
>     >     M.Sc. David Rupprecht
>     >
>     >     Ruhr-University Bochum
>     >     Research Group Information Security
>     >     Universitätsstraße 150
>     >     ID 2/130
>     >     44780 Bochum / Germany
>     >
>     >     Phone: +49 234 / 32 - 23508 <tel:+49%20234%203223508>
>     <tel:+49%20234%203223508>
>     >     Web: www.infsec.rub.de <http://www.infsec.rub.de>
>     <http://www.infsec.rub.de>
>     >
> 
>     --
>     M.Sc. David Rupprecht
> 
>     Ruhr-University Bochum
>     Research Group Information Security
>     Universitätsstraße 150
>     ID 2/130
>     44780 Bochum / Germany
> 
>     Phone: +49 234 / 32 - 23508 <tel:+49%20234%203223508>
>     Web: www.infsec.rub.de <http://www.infsec.rub.de>
> 

-- 
M.Sc. David Rupprecht

Ruhr-University Bochum
Research Group Information Security
Universitätsstraße 150
ID 2/130
44780 Bochum / Germany

Phone: +49 234 / 32 - 23508
Web: www.infsec.rub.de


More information about the srslte-users mailing list