You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Adel Boutros <Ad...@live.com> on 2017/01/18 15:57:47 UTC

[Proton 0.16.0 - Solaris] Null does not have a string representation

Hello,


I am actually testing the python bindings as described here [1]. I managed to launch the tests and have hit a new problem.


There is a class called pni_sasl_t in "sasl-internal.h". This struct has a lot of members which are pointers and set to NULL.


In the python test "proton_tests.sasl.SASLEventTest.testDisallowedMechClient", we arrive to a point where we call proton::transport.pending() which will arrive to "pni_post_sasl_frame" in proton-c/src/sasl/sasl.c and trigger an expected error:


case SASL_RECVED_OUTCOME_FAIL:
      pn_do_error(transport, "amqp:unauthorized-access", "Authentication failed [mech=%s]", transport->sasl->selected_mechanism);
      desired_state = SASL_ERROR;
      break;

However, "transport->sasl->selected_mechanism" is NULL and vsnprintf (in pn_do_error) cannot print a NULL. Thus it crushes.

On Linux, NULL is outputed as "(null)". This is why the same test doesn't crash there.

This issue seems problematic as it can happen in production.

Can you please advise on a proper fix?
I was thinking about maybe setting selected_mechanism to "NULL" string instead of NULL when we don't have a defined mechanism.

If you need more information, do not hesitate to ask.

Minimal test case which fails on Solaris but works on Linux
-----------------------------------------------------------------------------
#include <stdio.h>
#include <stdarg.h>

void work(int a, ...) {
    char *format = "Failed: %s";
    va_list va;
    va_start(va, format);

    char buf[30];
    vsnprintf(buf, 30, format, va);
}

int main() {
    work(3, NULL);
    return 0;
}

Solaris core (cc main.c)
---------------
 feea5b6c strlen   (8050786, 8047cc0, 8047c50, 0) + c
 fef03db7 vsnprintf (8047c8e, 1e, 805077c, 8047cc0, 0, 0) + 73
 0805070c work     (3, 0) + 2c
 0805072f main     (1, 8047cfc, 8047d04, fefa3ec0) + f
 0805064d _start   (1, 8047dac, 0, 8047db4, 8047db8, 8047dc8) + 7d


[1] http://qpid.2158936.n2.nabble.com/Proton-0-16-0-Compiling-Proton-Python-bindings-on-Solaris-is-failing-in-the-python-tests-td7657976.html

Regards,
Adel




Re: [Proton 0.16.0 - Solaris] Null does not have a string representation

Posted by Adel Boutros <Ad...@live.com>.
I have create a Jira issue with a patch attached which fixes the below error.


https://issues.apache.org/jira/browse/PROTON-1391


Regards,

Adel

________________________________
From: Adel Boutros <Ad...@live.com>
Sent: Wednesday, January 18, 2017 4:57:47 PM
To: users@qpid.apache.org
Subject: [Proton 0.16.0 - Solaris] Null does not have a string representation

Hello,


I am actually testing the python bindings as described here [1]. I managed to launch the tests and have hit a new problem.


There is a class called pni_sasl_t in "sasl-internal.h". This struct has a lot of members which are pointers and set to NULL.


In the python test "proton_tests.sasl.SASLEventTest.testDisallowedMechClient", we arrive to a point where we call proton::transport.pending() which will arrive to "pni_post_sasl_frame" in proton-c/src/sasl/sasl.c and trigger an expected error:


case SASL_RECVED_OUTCOME_FAIL:
      pn_do_error(transport, "amqp:unauthorized-access", "Authentication failed [mech=%s]", transport->sasl->selected_mechanism);
      desired_state = SASL_ERROR;
      break;

However, "transport->sasl->selected_mechanism" is NULL and vsnprintf (in pn_do_error) cannot print a NULL. Thus it crushes.

On Linux, NULL is outputed as "(null)". This is why the same test doesn't crash there.

This issue seems problematic as it can happen in production.

Can you please advise on a proper fix?
I was thinking about maybe setting selected_mechanism to "NULL" string instead of NULL when we don't have a defined mechanism.

If you need more information, do not hesitate to ask.

Minimal test case which fails on Solaris but works on Linux
-----------------------------------------------------------------------------
#include <stdio.h>
#include <stdarg.h>

void work(int a, ...) {
    char *format = "Failed: %s";
    va_list va;
    va_start(va, format);

    char buf[30];
    vsnprintf(buf, 30, format, va);
}

int main() {
    work(3, NULL);
    return 0;
}

Solaris core (cc main.c)
---------------
 feea5b6c strlen   (8050786, 8047cc0, 8047c50, 0) + c
 fef03db7 vsnprintf (8047c8e, 1e, 805077c, 8047cc0, 0, 0) + 73
 0805070c work     (3, 0) + 2c
 0805072f main     (1, 8047cfc, 8047d04, fefa3ec0) + f
 0805064d _start   (1, 8047dac, 0, 8047db4, 8047db8, 8047dc8) + 7d


[1] http://qpid.2158936.n2.nabble.com/Proton-0-16-0-Compiling-Proton-Python-bindings-on-Solaris-is-failing-in-the-python-tests-td7657976.html

Regards,
Adel




Re: [Proton 0.16.0 - Solaris] Null does not have a string representation

Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, 2017-01-18 at 15:57 +0000, Adel Boutros wrote:
> Hello,
> 
> 
> I am actually testing the python bindings as described here [1]. I
> managed to launch the tests and have hit a new problem.
> 
> 
> There is a class called pni_sasl_t in "sasl-internal.h". This struct
> has a lot of members which are pointers and set to NULL.
> 
> 
> In the python test
> "proton_tests.sasl.SASLEventTest.testDisallowedMechClient", we arrive
> to a point where we call proton::transport.pending() which will
> arrive to "pni_post_sasl_frame" in proton-c/src/sasl/sasl.c and
> trigger an expected error:
> 
> 
> case SASL_RECVED_OUTCOME_FAIL:
> ������pn_do_error(transport, "amqp:unauthorized-access",
> "Authentication failed [mech=%s]", transport->sasl-
> >selected_mechanism);
> ������desired_state = SASL_ERROR;
> ������break;
> 
> However, "transport->sasl->selected_mechanism" is NULL and vsnprintf
> (in pn_do_error) cannot print a NULL. Thus it crushes.

This is definitely a bug. We should never be trying to dereference a
null pointer (even if the Linux implementation of printf() is smart
enough to avoid this).

Andrew


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org