It's possible to get ORA-24345 error when you unload data with SQLULDR2, this error is due to no enough memory buffer allocated for column binding, the column data returned exceed the maximum length declared. After a full code review, there are two code bugs in SQLULDR2, but ociuldr doesn't have this bug.
For RAW data type, when unloading as text file, it will return hex string, each byte of the data will be returned as two hax char (the ascii code), so the memory buffer of this column type should be doubled. Now you can get ORA-24235 error, if you have RAW values larger than half precision size.
For number data type, when unloading negative values to text file, we should add one byte for the number value sign char, while it's ommited in current SQLULDR2. Somebody reported this problem when unload values stored in "NUMBER(2)" column, I finally found the root cause.
The ociuldr, previous release of SQLULDR2, doesn't have this bug, because ociuldr does not support fixed length text format, so for number type, I give 130 bytes memory buffer, for raw type, I give a 4000 bytes memory buffer. But in SQLULDR2, to well support of fixed length text format unload, I try to allocate as less buffer as possible.
However, if you already hit this bug, you can increase the precision of relative columns, or you can use "width" option to manually set the column width. I will get this bug fixed this week, you can update your binary next week. A new command line option ("safe") added to avoid ORA-24345 error.
It's possible we do some character set conversion when unloading data, from single byte to multiple bytes character set, the maximum length required may be doubled. If you set "safe" option to yes, SQLULDR2 will and 10 bytes for DATE, NUMBER column type, and double the memory bufer for character column type. So if you plan to do character set convertion, please set "safe" to yes, just call it "run in safe mode".