Order By causes crash on String columns (Mac API 1.2)

[PaulAustin]

I have a table with a string column 50 characters in length in a FGDB created by the API. In this case there are no nulls in the column but there could be.

If I use an order by clause on sql to the Geodatabase::ExecuteSQL method I get a crash of the program (see below). If I don't include the order by or use a numeric column then the program works fine. I have tried with the recycling parameter set to false and true but that makes no difference.

SELECT * FROM LOCALITY_POLY ORDER BY NAME

0   libsystem_kernel.dylib         0x00007fff8e12a212 __pthread_kill + 10
1   libsystem_c.dylib              0x00007fff88428af4 pthread_kill + 90
2   libsystem_c.dylib              0x00007fff8846cdce abort + 143
3   libsystem_c.dylib              0x00007fff88440959 free + 392
4   libfgdbunixrtl.dylib           0x0000000116c39d51 VariantClear(tagVARIANT*) + 161
5   libFileGDBAPI.dylib            0x0000000117042f0c FieldValues::~FieldValues() + 48
6   libFileGDBAPI.dylib            0x000000011708a8ea RecordSorter::Init(Datafile*, ScanContext*) + 800
7   libFileGDBAPI.dylib            0x00000001170585f4 Datafile::ExecuteScan(ScanContext&, int*) + 698
8   libFileGDBAPI.dylib            0x000000011709871b SqlSelectCommand::Execute() + 57
9   libFileGDBAPI.dylib            0x0000000116fa4f5c FileGDBAPI::Geodatabase::ExecuteSQL(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, bool, FileGDBAPI::EnumRows&) const + 136

As a side note I get a lot of crashes if I don't do something right in the API, it would be better for the API to include checks to avoid issues when dereferencing invalid pointers. For example invalid XML causes the whole program to crash rather than giving an error that the XML is invalid.

[LanceShipman]

I was able to reproduce this and I've entered it as NIM085995.

[DavidSousa]

We are not aware of crashes caused by bad XML.  Can you supply an example?

We do run all user supplied XML input through a validation process using the Geodatabase XML Schema Document (XSD).  There is additional validation as well.  If we find any problems, we return an error message.  It is possible that we have missed something, but without a repro case it is difficult to assess.

We recommend that any XML supplied as input first be validated by the user using the XSD that we ship with the API.  The XML should also be carefully reviewed with respect to the Geodatabase XML documentation that is shipped with the API.  There are a number of sample XML documents that can be used as a starting point for generating your own XML.

[PaulAustin]

Was the crash on order by for string columns ever fixed?