From: SourceForge.net <no...@so...> - 2007-05-12 02:38:56
|
Bugs item #1717166, was opened at 2007-05-11 05:36 Message generated for change (Comment added) made by miesfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1717166&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: APIs Group: None >Status: Pending >Resolution: Fixed Priority: 7 Private: No Submitted By: Rick McGuire (bigrixx) Assigned to: Mark Miesfeld (miesfeld) Summary: Queue Push fails when larger than 7128 Initial Comment: This appears to be related to the Vista changes, but I'm not sure what the actual problem is. Here's a simple program to recreated this: /* The break point for this example is 7129 If the do loop is 7128 it works ok if the do loop is 7129, the Push fails with: Open Object Rexx Interface has encountered a problem and need to close. AppName: rexxexe AppVer: 3.1.2.1 ModName: rexxapi.dll ModVer: 3.1.2.1. Offset: 00001fe4 */ Do i = 2 to 7129 a = a||'A' end say 'Length:'Length(a) Push a Pull b say b The queue elements are transmitted to the rxapi server using shared memory, and there's logic to extend the shared memory buffer when necessary. However, it appears that something is miss firing in the buffer reallocation. When the client attempts to access the newly allocated buffer after sending the extend method to the rxapi process, it appears to be getting the original buffer back again. This causes a trap when it attempts to copy the queue data back into the buffer. ---------------------------------------------------------------------- >Comment By: Mark Miesfeld (miesfeld) Date: 2007-05-11 19:38 Message: Logged In: YES user_id=191588 Originator: NO This is fixed in SVN with revision 370. The mechanism used by RxAPI to increase the shared memory buffer is to create a new larger memory mapped file. All the handles and views of the old memory mapped file need to be closed. When QueuesAPI.c and MacroSpace.c requested a new larger buffer, they were closing the handles and view of the old buffer after RexxAPIService had already created the new buffer. This was fine when using unamed memory mapped files. However it failed when using named memory objects because, if the object already exists, CreateFileMapping will return a handle to the existing object with the current size, rather than the new size. The fix was to have QueueAPI and MacroSpace close their handles and views prior to requesting the larger buffer. Then when RexxAPIService goes to create the new larger memory mapped file, a truely new memory object is created because the old memory object, of the same name, has been closed. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2007-05-11 10:18 Message: Logged In: YES user_id=191588 Originator: NO Okay, I see the exact problem. It comes from switching to an un-named memory mapped file to a named memory mapped file: If the object exists before the function call, the function returns a handle to the existing object (with its current size, not the specified size), and GetLastError returns ERROR_ALREADY_EXISTS. I'll fix this tonight. Unfortunately, this is going to hit every case where the shared memory buffer needs to be extended. ;-( ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2007-05-11 06:13 Message: Logged In: YES user_id=191588 Originator: NO Yikes. I'll look at this right after work today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1717166&group_id=119701 |