Segmentation fault running spicy-driver using %context / self.context()

[awelzel]

Observing a segfault with the following parser when running it through spicy-driver:

$ cat context-crash.spicy 
module Test;

type State = tuple<ssl_requested: uint8>;

type X = unit {
  val: bytes &size=3 {
    if ( self.val == b"ssl" )
        self.context().ssl_requested = 1;
  }
};

public type Y = unit {
  %context = State;
  x: X;
};

$ docker pull zeekurity/spicy:latest                                                               
latest: Pulling from zeekurity/spicy                                                                                                                                    
Digest: sha256:0bab492a0e2a68d05cf69c2aa56f2e9c56a7f66162c3acf280acc665593d4254                                                                                         
Status: Image is up to date for zeekurity/spicy:latest                            
docker.io/zeekurity/spicy:latest                                                    
$ docker run -v $(pwd):/src -w /src  -it --rm  zeekurity/spicy-dev:latest
# spicyc --version
spicyc v1.6.0-dev.118 (258565a4)
# spicy-driver ./context-crash.spicy
Segmentation fault (core dumped)

Maybe self.context() isn't allowed in non-public types, but the segfault does not help to figure out what I'm doing wrong :-)

[bbannier]

The issue here is that we are missing a validation¹. The call to ssl.context() is invalid in X since it does not have a context, and we should reject the code (once a context is added, there will be an additionl validation kicking in that ensures that the unit with the context is public).

The workaround here is to make sure that every unit which makes use of self.context() also declares a context.

Footnotes

1. There is an assertion in the code that we can resolve the type of the context. This check is not triggered in a release build and we instead attempt to pull a value out of an unset optional which triggers the segfault. ↩