From: SourceForge.net <no...@so...> - 2007-05-11 13:13:46
|
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: Open Resolution: None Priority: 5 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 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 |