msUpdateClassFromString segfaults when class is not in a layer

[sgillies]

Since version 4.4 (maybe even earlier), we've been allowing users to create independent classObjs like

  >>> co = mapscript.classObj()

My current implementation of mapscript.fromstring (for RFC 31) leverages that to create new classObjs from a string:

  >>> co = mapscript.classObj()
  >>> co.updateFromString(data)

Currently, msUpdateClassFromString assumes that a classObj has a parent layerObj and we get a segfault. From running the doctest:

Trying:
    co = mapscript.fromstring("""CLASS END""")
Expecting nothing

Program received signal SIGSEGV, Segmentation fault.
---Type <return> to continue, or q <return> to quit---
[Switching to Thread -1210665296 (LWP 23390)]
0xb797394a in msUpdateClassFromString (class=0x825c0b8, 
    string=0xb7a5a304 "CLASS END", url_string=0) at mapfile.c:2277
2277      if(loadClass(class, class->layer->map, class->layer) == -1) {

class->layer is NULL at that point. Solution: do not dereference class->layer if it is NULL.

[sdlime]

Sean: Should msUpdateClassFromString() just return silently then if !class->layer? I don't see an alternative although I should see if we could plod through loading sub-objects with a NULL map or layer. Basically the loadObject functions would need to be more bullet proof...

Steve

[sgillies]

The only use loadClass makes of the map is as a container for the templatepattern. I suggest we change the signature of loadClass from

int loadClass(classObj *class, mapObj *map, layerObj *layer)

to

int loadClass(classObj *class, char *templatepattern, layerObj *layer)

I also just noticed that loadClass never even uses the layer parameter. That should be eliminated while we're at it. loadClass is only called 3 times in mapfile.c so it's a small fix.

[sdlime]

Sounds ok, could you make the change?

Steve

[sgillies]

Committed to r6542. Mapscript tests look ok, no related failures. Try it out?

[sdlime]

I believe this one is good to go... Thanks Sean!

Steve