[srslte-users] Seg fault in scrambling_b_word

Ismael Gomez ismael.gomez at softwareradiosystems.com
Tue Jul 11 11:19:24 UTC 2017


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> 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>> 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>>>
> >     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 <+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>
> >     >>>     _______________________________________________
> >     >>>     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
> >     >>>
> >     >>
> >     >
> >
> >     --
> >     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 <+49%20234%203223508>
> <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 <+49%20234%203223508>
> Web: www.infsec.rub.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.softwareradiosystems.com/pipermail/srslte-users/attachments/20170711/55a9379c/attachment-0001.html>


More information about the srslte-users mailing list