[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 srsran-users
mailing list