segfault in msEvalExpression

[each2]

FC12 x64, 5.6.5 from source.

on large WMS rendering project, got a segfault in maputil.c's msEvalExpression where it appears possible that items can be null, thus the strcasecmp bails out non-gracefully on line 374. Could replicate locally but not sure exactly what was causing the problem - was using 80GB of tiled shapefiles as input. My "quick and dirty hack" was simply to ignore the condition that could cause mapserver to die, and return a MS_FALSE, like so:

if(expression->flags & MS_EXP_INSENSITIVE) {

if(strcasecmp(expression->string, items[itemindex]) == 0) return(MS_TRUE); /* got a match */

} else {

Dirty Hack, stops segfault

if ( items == 0x0 )

return(MS_FALSE);

End dirty hack

if(strcmp(expression->string, items[itemindex]) == 0) return(MS_TRUE); /* got a match */

} break;

If nothing else, this at least prevents the bailout, but is not addressing the actual cause of WHY items could be null in the first place. Would suggest this "fix" is implemented regardless as defensive programming at the very least!

Regards

Dave Pearson

[sdlime]

Can you share layer defs? Are you seeing the error on getMap or getInfo? Does the error occur with non-wms calls?

Steve

[each2]

Hi Steve, it was during a pre-seed of UK mapping using tilecache with OS OpenData Vector District. Shapefiles were used with tileindex, so WMS calls would have been getMap. Unfortunately I needed to complete the job very quickly so although I could repeat the bug (which is how I managed to find it with gdb) I didn't at the time have the luxury of time to isolate the case. I did manage to replicate the same error using shp2img so that discounts a problem with WMS alone. By all means keep the ticket open and the next time it happens with a newer version I'll send the backtrace and try and isolate whatever is going on to provide you with the relevant data. My suspicion (call it "gut feel") is that it's a single shapefile that is somehow corrupted, so it may have geometry and no data (this would explain the null coming through unchallenged) and then being parsed by a EXPRESSION that bombs out the whole job (I have lots of EXPRESSIONs in the mapfile). Like I say, it's a big tilecache pre-seed, so it was killing the whole task - thus my "dirty hack" which at least allowed the job to finish to completion. I know errors in shapefiles have been discussed before many times, and how it shouldn't be up to MS to have to deal with these things, but if it can cause a fatal segfault I feel at least some resilience against a non-graceful exit following a bad string comparison should be provided, what do you think? I'm quite happy to just keep patching newer versions if you feel this is too vague to incorporate into the code just yet.

Regards

Dave Pearson