Java mapscript problem with strings longer then 2k used as Oracle filter

[maurosa]

Java mapscript problem with strings longer then 2k used to specify data sql connection query or filter with Oracle 10g data source. Mapscript crashes when it executes setFilter. I suspect there is a general issue with long strings, a memory allocation problem. The same string used directly in the mapfile works correctly.

The mapscript code to reproduce the error is:

layerObj layer = map.getLayerByName("LAYER"); String sFilter = "CODE IN ('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','25','26','27','28','29','30','31','32','33','34','35','36','37','38','39','40','41','42','43','44','45','46','47','48','49','50','51','52','53','54','55','56','57','58','59','60','61','62','63','64','65','66','67','68','69','70','71','72','73','74','75','76','77','78','79','80','81','82','83','84','85','86','87','88','89','90','91','92','93','94','95','96','97','98','99','100','101','102','103','104','105','106','107','108','109','110','111','112','113','114','115','116','117','118','119','120','121','122','123','124','125','126','127','128','129','130','131','132','133','134','135','136','137','138','139','140','141','142','143','144','145','146','147','148','149','150','151','152','153','154','155','156','157','158','159','160','161','162','163','164','165','166','167','168','169','170','171','172','173','174','175','176','177','178','179','180','181','182','183','184','185','186','187','188','189','190','191','192','193','194','195','196','197','198','199','200','201','202','203','204','205','206','207','208','209','210','211','212','213','214','215','216','217','218','219','220','221','222','223','224','225','226','227','228','229','230','231','232','233','234','235','236','237','238','239','240','241','242','243','244','245','246','247','248','249','250','251','252','253','254','255','256','257','258','259','260','261','262','263','264','265','266','267','268','269','270','271','272','273','274','275','276','277','278','279','280','281','282','283','284','285','286','287','288','289','290','291','292','293','294','295','296','297','298','299','300','301','302','303','304','305','306','307','308','309','310','311','312','313','314','315','316','317','318','319','320','321','322','323','324','325','326','327','328','329','330','331','332','333','334','335','336','337','338','339','340','341','342','343','344','345','346','347','348','349','350','351','352','353','354','355','356','357','358','359','360')"; layer.setFilter(sFilter);

if sFilter length exceeds circa 2020 character, "layer.setFilter" crashes.

The same filter used in a mapfile directly works:

MAP

EXTENT 332297.498779193 4755335.20218117 1022948.803155 5253971.36953255 FONTSET "fonts/fonts.list" IMAGECOLOR 255 255 255 IMAGETYPE JPEG SYMBOLSET "symbols/symbols.sym" SIZE 688 497 STATUS ON UNITS METERS NAME "MAP" OUTPUTFORMAT

NAME "JPEG" MIMETYPE "image/jpeg" DRIVER "AGG/JPEG" EXTENSION "jpg" IMAGEMODE "RGB" TRANSPARENT FALSE FORMATOPTION "QUALITY=95"

END PROJECTION

"init=epsg:32632"

END LAYER

CONNECTION "USR/PWD@sid" CONNECTIONTYPE ORACLESPATIAL DATA "GEOMETRY FROM TABLE USING UNIQUE ID SRID 8307 RELATE VERSION 10g" FILTER "CODE IN ('1','2','3','4','5','6','7','8','9','10','11','12','13','14','15','16','17','18','19','20','21','22','23','24','25','26','27','28','29','30','31','32','33','34','35','36','37','38','39','40','41','42','43','44','45','46','47','48','49','50','51','52','53','54','55','56','57','58','59','60','61','62','63','64','65','66','67','68','69','70','71','72','73','74','75','76','77','78','79','80','81','82','83','84','85','86','87','88','89','90','91','92','93','94','95','96','97','98','99','100','101','102','103','104','105','106','107','108','109','110','111','112','113','114','115','116','117','118','119','120','121','122','123','124','125','126','127','128','129','130','131','132','133','134','135','136','137','138','139','140','141','142','143','144','145','146','147','148','149','150','151','152','153','154','155','156','157','158','159','160','161','162','163','164','165','166','167','168','169','170','171','172','173','174','175','176','177','178','179','180','181','182','183','184','185','186','187','188','189','190','191','192','193','194','195','196','197','198','199','200','201','202','203','204','205','206','207','208','209','210','211','212','213','214','215','216','217','218','219','220','221','222','223','224','225','226','227','228','229','230','231','232','233','234','235','236','237','238','239','240','241','242','243','244','245','246','247','248','249','250','251','252','253','254','255','256','257','258','259','260','261','262','263','264','265','266','267','268','269','270','271','272','273','274','275','276','277','278','279','280','281','282','283','284','285','286','287','288','289','290','291','292','293','294','295','296','297','298','299','300','301','302','303','304','305','306','307','308','309','310','311','312','313','314','315','316','317','318','319','320','321','322','323','324','325','326','327','328','329','330','331','332','333','334','335','336','337','338','339','340','341','342','343','344','345','346','347','348','349','350','351','352','353','354','355','356','357','358','359','360')" NAME "LAYER" PROJECTION

"init=epsg:4326"

END STATUS ON TYPE POLYGON CLASS

STYLE

OUTLINECOLOR 80 100 80 SIZE 3 SYMBOL 1

END

END

END

END

[unicoletti]

The problem is not in Java itself, but in the error handling function and the crash will probably only happen when the sql string is not correct: when oracle returns an error the erroneous sql query is formatted with a vsprintf into a char[2048] without checking its length. By changing the sprintf to a vsnprintf the problem went away because the output is truncated to 2048. This is also consistent with your finding that the crash happens at around 2020 characters if you consider that the same char[2048] also receives some additional text before the query.

Index: maperror.c =================================================================== --- maperror.c (revision 7176) +++ maperror.c (working copy) @@ -333,7 +333,7 @@

else {

va_start(args, routine);

• vsprintf( ms_error->message, message_fmt, args );

+ vsnprintf( ms_error->message, MESSAGELENGTH, message_fmt, args );

va_end(args);

}

The change has been commited to cvs, please report success.

Sorry that it took so long to reply.

[aalbarello]

Looks like this has not been backported to 5.0 which made me lose a half day's work. It does indeed solve the problem, but it would have been nice if this were included in 5.0.2 or in upcoming 5.0.3, for that matter.

Andreas

[sdlime]

Reopening and setting milestone to 5.0.3...

Steve

[dmorissette]

V5.0 is no longer supported. Since the fix is in the current releases and this ticket has not been touched in 2 years, let's close it.