help-gsasl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segmentation fault on


From: Simon Josefsson
Subject: Re: Segmentation fault on
Date: Sun, 28 Mar 2010 21:28:58 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

jonathan lyons <address@hidden> writes:

> Hello all,
>
> I'm hoping you can help me with an issue.
>
> I'm trying to use SASL to authenticate with an XMPP server (in a TLS
> encrypted session) . However, when I use the gsasl_step64() function my
> program segfaults.

Hi!  Are you implementing the client or server side?  Which GNU SASL
version?

> Here is the area where it is segfaulting:
>
> void xmpp_sasl::perform_authentication() {
>     char buf[8192] = "";
>     char *p;
>     int rc;
>
>     do {
>         rc = gsasl_step64(session, buf, &p);
>
>         if (rc == GSASL_NEEDS_MORE || rc == GSASL_OK) {
>             this->connection->send_string(buf, 8192);
>            free(p);
>         }
>
>         this->clear(buf, 1024);
>         if (rc == GSASL_NEEDS_MORE) {
>             this->connection->receive_string(buf, 8192);
>
>         }
>
>     } while (rc == GSASL_NEEDS_MORE);
>
> I have isolated gsasl_step64 as the place where the fault occurs .  All of
> the client and session initialization(in different functions) appears to go
> just fine, so session seems like it is a valid pointer.
>
> I know it is bad to use a fixed-size buffer, but it is just temporary..
>
> has anyone else experienced this problem?

Hi!  Can you get a gdb backtrace when the crash happens?

The immediate cause for the crash MAY be that buf is the empty string
rather than NULL, but the library shouldn't crash on that anyway.  But
the explanation could also be something entirely different.  The answer
could also be that you ran into a bug in the SCRAM implementation,
solved in v1.4.4:

** SCRAM: Don't read out of bounds when parsing tokens.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]