Hi there, while trying to create a 64-bit version of ooRexx for Linux, I noticed that the enclosed patch has not yet been applied to trunk.
If the patch is o.k. as such, I would request the ooRexx team to apply it. Reason being, that people on Ubuntu/Linux can fetch the latest ooRexx binary from the build machine, if they wish to check out the OOo-binding of BSF4ooRexx. Without that patch, it may not be possible for interested people to run any OOo ooRexx scripts successfully. (Since I applied the patch to the 32-bit ooRexx on Ubuntu no problems have occurred.) TIA, ---rony On 17.08.2010 15:05, Rony G. Flatscher wrote: > Done: > > * bug report > > <https://sourceforge.net/tracker/?func=detail&aid=3046998&group_id=119701&atid=684730> > containg link to the > * patch at: > > <http://sourceforge.net/tracker/?func=detail&aid=3046995&group_id=119701&atid=684732>. > > Many thanks! > > ---rony > > > On 17.08.2010 13:56, Rick McGuire wrote: >> Please open a tracker for this. >> >> Rick >> >> On Tue, Aug 17, 2010 at 7:44 AM, Rony G. Flatscher >> <rony.flatsc...@wu-wien.ac.at> wrote: >> >>> Removing the fileno(handle) block in FileSystem.cpp resolves the problem! >>> (It seems that this removal is o.k. as we received already a valid file >>> handle at that point, which should not be the case if the maximum open file >>> handles was exceeded already.) >>> >>> Shall I open a tracker with a patch for this? (Alternatively, I tried to >>> picture the block that needs to be removed.) >>> >>> ---rony >>> >>> >>> On 16.08.2010 20:32, Rick McGuire wrote: >>> >>> Hmmm, taking a quick look at the code and the places where the file >>> unreadable error can be triggered, I found the following lines in >>> FileSystem.cpp: >>> >>> >>> RexxBuffer *SystemInterpreter::readProgram(const char *file_name) >>> /*******************************************************************/ >>> /* Function: Read a program into a buffer */ >>> /*******************************************************************/ >>> { >>> FILE *handle; /* open file access handle >>> */ >>> size_t buffersize; /* size of read buffer >>> */ >>> { >>> handle = fopen(file_name, "rb"); /* open as a binary file >>> */ >>> if (handle == NULL) >>> { /* open error? */ >>> return OREF_NULL; /* return nothing >>> */ >>> } >>> >>> if (fileno(handle) == (FOPEN_MAX - 2)) >>> { /* open error? */ >>> return OREF_NULL; /* return nothing >>> */ >>> } >>> >>> fseek(handle, 0, SEEK_END); /* seek to the file end >>> */ >>> buffersize = ftell(handle); /* get the file size >>> */ >>> fseek(handle, 0, SEEK_SET); /* seek back to the file >>> beginning */ >>> } >>> RexxBuffer *buffer = new_buffer(buffersize); /* get a buffer >>> object */ >>> ProtectedObject p(buffer); >>> { >>> UnsafeBlock releaser; >>> >>> fread(buffer->getData(), 1, buffersize, handle); >>> fclose(handle); /* close the file >>> */ >>> } >>> return buffer; /* return the program buffer >>> */ >>> } >>> >>> >>> I don't understand the purpose of the "fileno(handle) == (FOPEN_MAX - >>> 2)" test, but that certainly could be the cause of this error. It's >>> consistent with the fact that this error occurs even if you change the >>> name of the file. This test appears to be something pulled forward >>> from the 3.2.0 code, but I don't know of any reason why that should >>> have been there in the first place. >>> >>> Given the number of files that the jvm generally has open, it is >>> certainly conceivable that we're hitting a window where that's true. >>> >>> Rick >>> >>>
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
