From: SourceForge.net <no...@so...> - 2007-05-15 00:04:57
|
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-14 17:04 Message: Logged In: YES user_id=191588 Originator: NO Rick's changes in revision 371 do fix this bug, so I am putting it back in pending. ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2007-05-12 06:01 Message: Logged In: YES user_id=1125291 Originator: YES Mark, there's still a problem here. If there are two active processes using Rexx, this will still fail because one of the processes will still have an active handle to the original memory segment. Here's a modification to the original program that can demonstrate the problem. /* 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 */ push 'abc' pull pull Do i = 2 to 7129 a = a||'A' end say 'Length:'Length(a) Push a Pull b say b Run this in two command windows and allow it to set at the prompt. Then hit enter in one of the windows. The original trap will still occur. I had some time this morning, so I took a look at this. I fixed the problem by dynamically creating the name used for the QUEUE and MACRO com blocks. The dynamic name just concatenates the current extension level to the mapping name so that a new named memory segment is created each time an extension occurs. Eventually, each of the client processes will catch up with the change and close the original named segment and map in the new one. The changes were committed in revision 371. ---------------------------------------------------------------------- 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 |