nanogui: Thread: Image size limit?

> I also added 50000 to GrNewBitmapFromData malloc() but still failed.

Well, now we need to trace the GrBitmap function in 
the server, since that's what's crashing, not the client, right?

Lets printf through the server case (remember to add
fflush(stdout) to see it after every printf) and we'll
find the exact location its dying.  An easier method is to
run gdb on the server from a remote telnet terminal, and
do a stack backtrace.

Regards,

Greg

One assert error message that may have something to do with it:
in nxproto.c line 41, in function nxAllocReq tests the size of the buffer to be <= MAXREQUESTSZ which is printed to strerr as 30000.
Why is the assertion triggered and what is it for?

Martin


-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thursday, July 13, 2006 1:21 PM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] RE: Image size limit?


> I also added 50000 to GrNewBitmapFromData malloc() but still failed.

Well, now we need to trace the GrBitmap function in 
the server, since that's what's crashing, not the client, right?

Lets printf through the server case (remember to add
fflush(stdout) to see it after every printf) and we'll
find the exact location its dying.  An easier method is to
run gdb on the server from a remote telnet terminal, and
do a stack backtrace.

Regards,

Greg

> One assert error message that may have something to do with it:
in nxproto.c line 41, in function nxAllocReq tests the size of the buffer to 
be <= MAXREQUESTSZ which is printed to strerr as 30000.
Why is the assertion triggered and what is it for?

This checks the mechanism that always divvies up bitmaps
to be less than MAXREQUESTSZ bytes down the
line in a single nano-X packet.  In this way, we won't
block a low-level socket write() nor try to write more
data than a simple system can handle.  If this assert
fires, it means there's problems in client.c/srvnet.c,
which handle the packetizing of all requests.

Regards,

Greg

Looking at the client.c and GrBitmap (where it fails), I do not see the
division of transfers into MAXREQUESTSZ size chunks when in fact other
functions (not all) have this logic.

Should it also be implemented in GrBitmap and it was not?
Why some functions have this and others do not? Oversight or playing lucky?

I guess that some functions do not expect the transfers to be large to begin with
but in case of BrBitmap it could happen (in my case 49000 bytes vs. 30000 limit)

Should I fix GrBitmap or the problem lies somewhere else?
Martin



-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Thursday, July 13, 2006 4:34 PM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] RE: Image size limit?


> One assert error message that may have something to do with it:
in nxproto.c line 41, in function nxAllocReq tests the size of the buffer to 
be <= MAXREQUESTSZ which is printed to strerr as 30000.
Why is the assertion triggered and what is it for?

This checks the mechanism that always divvies up bitmaps
to be less than MAXREQUESTSZ bytes down the
line in a single nano-X packet.  In this way, we won't
block a low-level socket write() nor try to write more
data than a simple system can handle.  If this assert
fires, it means there's problems in client.c/srvnet.c,
which handle the packetizing of all requests.

Regards,

Greg

I fixed the GrBitmap to send data in chunks and it works.
The problem is fixed.

This made sense to me once I understood the limitations of the transfer routines and that some pieces of code do not break up the transfers.

I will email the fix soon.
Martin

The fix (diff) is attached.
Martin

> I fixed the GrBitmap to send data in chunks and it works. The problem is
fixed.

Woohoo!


> This made sense to me once I understood the limitations of the transfer
routines and that some pieces of code do not break up the transfers.

Martin, thanks for the code fix.  This was definitely an oversight.  I
thought I had all cases where variable length data was sent, handled.
What other routines did you see that might require fixing also?

Another thought is: perhaps the server should check that no
request is sent with a length value > MAXREQUESTSZ.  In
this way, it wouldn't just crash, but could drop the request.
I need to look at the code to see why this isn't already handled
properly, that was the reason for the length word in the first
place - the packet should at least have been read properly
from the client request socket.

Regards,

Greg

I agree that the server should not crash and do something reasonable.
I did not look at other routines but everywhere there is a memcpy call, 
it should be investigated if similar fix is required. 
Some calls already have that, this is how I got my fix, but not all.

Martin

-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Friday, July 14, 2006 6:29 PM
To: Martin Kajdas; ####@####.####
Subject: Re: [nanogui] RE: Image size limit?


> I fixed the GrBitmap to send data in chunks and it works. The problem is
fixed.

Woohoo!


> This made sense to me once I understood the limitations of the transfer
routines and that some pieces of code do not break up the transfers.

Martin, thanks for the code fix.  This was definitely an oversight.  I
thought I had all cases where variable length data was sent, handled.
What other routines did you see that might require fixing also?

Another thought is: perhaps the server should check that no
request is sent with a length value > MAXREQUESTSZ.  In
this way, it wouldn't just crash, but could drop the request.
I need to look at the code to see why this isn't already handled
properly, that was the reason for the length word in the first
place - the packet should at least have been read properly
from the client request socket.

Regards,

Greg