1. I think you said you are allocating an intermediate buffer for
debugging. Otherwise, you could call http_cl.ReceiveBytes() directly
with pData and pSize.
2. I suggested checking the value of pData to see if it is a
reasonable value, but only while you are debugging the problem.
Normally, you expect the value to be passed correctly, but if it
isn't, then it could be a clue.
3. If you are certain that none of your routines are corrupting memory
by writing to incorrect locations, and that you are faithfully
communicating the contents of the prc to ExgMgr, then I can only
assume there is a problem with ExgMgr. A problem of this type with
ExgMgr is unlikely, however. Can you use the debugger (or serial
tracing) to step through the whole process? I suspect that at some
point a write occurs to the wrong address, or the prc content gets
confused.
On 10/26/07, Ryan Dorn <[EMAIL PROTECTED]> wrote:
> Thank you for the reply,
>
> 1. I completely forgot to release the buffer that I
> allocated, so I corrected that and also checked the
> return value of MemPtrNew. My http_cl.ReceiveBytes()
> works fairly similarly to this exgReadProc, you send
> it a buffer to place data in and tell it the size of
> the buffer. It receives the data from the socket, and
> if it can't fill the entire buffer, it sets the UInt32
> sent to it to the amount of bytes actually received.
> So, before making the call, I set "bytes_received" to
> the value coming in from *pSize, and when it returns,
> I set *pSize back to however many bytes the socket
> received.
>
> 2. I'm not sure I understand, doesn't pData point to a
> chunk of dynamic memory already allocated by the
> ExgDBRead function? Do I need to be doing any
> checking on this buffer before I do any data moving?
> I've always assumed that this will be correctly
> allocated and I won't have to do anything to check it.
> After my socket receives the bytes, I'm moving the
> data from buf (where the socket puts the data) into
> pData (the pre-allocated chunk of memory for the
> Exchange Manager).
>
> 3. I'm fairly certain that my class is returning the
> correct data and size. I placed some custom alerts in
> the procedure so I could see what was coming back from
> the stream as I viewed the actual .prc file on my PC
> using a hex editor. The values were getting read up
> correctly.
>
> The thing is, it ALWAYS errors out at the same point
> on this one specific file. It reads the first 72
> bytes OK, then the next 6 bytes OK, then it goes
> through a loop of 10-byte blocks, and after about 15
> of these 10-byte chunks, it crashes. And I've
> confirmed that the crash does not happen in my
> exgReadProc, it happens after I return and before the
> procedure hits again. I also noticed that MemMove
> takes a signed Int32 for size so I thought that might
> have been the problem since I was passing a UInt, but
> I made a cast and it's still doing the same thing.
>
> Could there be a problem using a Char* pointer, should
> I use some other datatype for the buffer?
>
> Here is my updated exgReadProc:
>
> Err exgReadProc(void *pData, UInt32 *pSize, void
> *pUserData) {
> Char *buf = (Char *)MemPtrNew(*pSize);
> if (buf == NULL) {
> FrmCustomAlert(str_error, "Error allocating
> memory", "", "");
> *pSize = 0;
> return 0;
> }
> UInt32 bytes_received = *pSize;
> http_cl.ReceiveBytes(buf, &bytes_received);
> MemMove(pData, buf, (Int32)bytes_received);
> *pSize = bytes_received;
> MemPtrFree(buf);
> }
> --- Jeff Loucks <[EMAIL PROTECTED]> wrote:
>
> > Off the top of my head...
> > 1. What are the values passed at *pSize? You don't
> > check the return
> > value of MemPtrNew(), so it could be failing. And,
> > since it is not
> > apparent that you ever free the allocated memory,
> > it's possible you
> > are running out of memory.
> > 2. Where does pData point? I assume you don't
> > actually do a
> > MemPtrNew() in the real code, because there's no
> > reason for it. When
> > you do the MemMove(), where are you moving the data
> > to?
> > 3. You claim the http class is reading the socket
> > correctly, but I
> > don't see the class, so cannot be certain there are
> > no side effects.
> > Are you sure the http class works as expected?
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> --
> For information on using the ACCESS Developer Forums, or to unsubscribe,
> please see http://www.access-company.com/developers/forums/
>
--
[Jeff Loucks, Gig Harbor, WA, USA]
--
For information on using the ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
