Chronological Thread 

< Chronological >      < Thread >

---

> -----Original Message-----
> From: Michael Tüxen
> [mailto:Michael.Tuexen AT micmac.franken.de]
> Sent: donderdag 26 april 2001 9:36
> To:
> discussion AT sctp.de
> Subject: Re: [SCTP-Discussion] sctp_receive produces segfaults
>
>
> Dear all,
>
> we want to let you know that the SEGFAULT problem was caused
> by wrong library usage and not by the sctplib implementation itself.
>
> In the sctp_receive call the user MUST provide the memory space for
> the packet and passes a pointer to that user allocated memory to the
> library. Please look into the examples.

That was my fault. the receive buffer was just a pointer to. Must be a real
variable.
Put this in code and it now works. Thank you very much for the suport.

Happy SCTPing to everybody over there...

>
> Best regards
> Michael
>

Yours sincerly,
Lode


Siemens Atea ICN D CS D
Software Development
Atealaan 34
B-2200 Herentals Belgium
Tel +32-14-25-2081 / Fax +32-14-25-3212
E-mail:
lode.coene AT siemens.atea.be

> > >
> > > > Coene Lode wrote:
> > > > >
> > > > > Well folks,
> > > > >
> > > > > Upgrading to SCTPlib-1.0.0-Pre9, I got accross the follwing
> > > > problem which
> > > > > did not occur in the pre6(the one I was previously using).
> > > > > Every time I call sctp_receive, a segfault is signalled at
> > > > > DLL_DeleteCurrentRecord line 900(module DLL_main.c)
> when readin
> > > > > list->current->info. it seems it is reading into the middle
> > > > of nowhere(thus
> > > > > generating the segmentation fault.
> > > > > There may something wrong in my software because a older
> > > > version does the
> > > > > SCTP_receive without segfault, but produces a goblygook
> > > > bytestring, which
> > > > > was not the bytestring that was send(however the length is
> > > > correct, so there
> > > > > must be something there) Was checked via ethereal: DATA
> > > > send , SACK went
> > > > > back
> > > > > My conclusion: sctp_receive copies data from the "middle of
> > > > nowhere" to me.
> > > > > Reason: I don't know.
> > > > >
> > > > > As a aside note: in the previous version pre6, the
> > > > association id was always
> > > > > a big number 8596726(example) and always different from the
> > > > previous one.
> > > > > Now in the pre9 version I always get 1 which is the same as
> > > > the previous
> > > > > one.(Which is weird to say the least) Maybe this has
> > > > something to do with my
> > > > > troubles.
> > > > >
> > > > > In order to check this out again I am going to put in pre6
> > > > and test it
> > > > > again.
> > > > >
> > > > > yours sincerly,
> > > > > Lode
> > > > >
> > > > > PS: note to myself: if it works, don't upgrade
> > > > >
> > > > > Siemens Atea ICN D CS D
> > > > > Software Development
> > > > > Atealaan 34
> > > > > B-2200 Herentals Belgium
> > > > > Tel +32-14-25-2081 / Fax +32-14-25-3212
> > > > > E-mail:
> > > > > lode.coene AT siemens.atea.be

---

• [SCTP-Discussion] sctp_receive produces segfaults, Coene Lode, 04/25/2001
  • Re: [SCTP-Discussion] sctp_receive produces segfaults, Michael Tüxen, 04/25/2001
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] sctp_receive produces segfaults, Coene Lode, 04/25/2001
    • Re: [SCTP-Discussion] sctp_receive produces segfaults, Michael Tüxen, 04/25/2001
      • Re: [SCTP-Discussion] sctp_receive produces segfaults, Michael Tüxen, 04/26/2001
  • RE: [SCTP-Discussion] sctp_receive produces segfaults, Coene Lode, 04/25/2001
    • [SCTP-Discussion] SCTP code in solaris, prashant kerur, 04/26/2001
      • Re: [SCTP-Discussion] SCTP code in solaris, Tomas Kukosa, 04/26/2001
  • RE: [SCTP-Discussion] sctp_receive produces segfaults, Coene Lode, 04/26/2001

---

Archive powered by MHonArc 2.6.19+.