Hi Greg
Greg Haerr schrieb:
[...]
The X11 driver keeps "savebits" by commanding X11, then
drawing using the fb32 driver. It looks like perhaps the
size malloced could be incorrect. This is calced in the genmem.c
file, I think, but you'll need to look hard at the X11 driver to
trace where it alloced the savebits fb buffer in the first place.
I'm not aware of any X11 driver problems, so its a bit strange...
Regards,
Greg
I found the following:
The size malloced in scr_x11.c is calculated by GdCalcMemGCAlloc(..)
which returns 1228800 (= 640*480*4) for TrueColor (32bit).
savebits.addr is of type ADDR32 which is a typedef to a long*. On my
64bit system, a long is 8 bytes, so the calculation
"addr += x1 + y * psd->linelen;"
in fblin32.c adds x1+y*psd->linelen*8 bytes (instead of 4 bytes, which
were used for calculating the size for mallocing). That's the reason why
I have the segfault when calculating with y=241.
I changed in drivers/fb.h the typedefs for ADDR8, ADDR16 and ADDR32 to
the standard sized types u_int8_t, u_int16_t and u_int32_t.
Thanks for the input!
Best regards
Pascal
*** fb.h.old 2008-04-23 21:15:24.000000000 +0200
--- fb.h 2008-04-23 21:21:01.000000000 +0200
***************
*** 22,30 ****
#define DRAWOFF
#endif
! typedef unsigned char * ADDR8;
! typedef unsigned short * ADDR16;
! typedef unsigned long * ADDR32;
/* Note that the following ROP macro implements the
* Porter-Duff rules assuming that source and destination
--- 22,31 ----
#define DRAWOFF
#endif
! // changes by P. Tritten, setting size explicitly, because of 32/64bit long (Linux amd64)
! typedef u_int8_t * ADDR8;
! typedef u_int16_t * ADDR16;
! typedef u_int32_t * ADDR32;
/* Note that the following ROP macro implements the
* Porter-Duff rules assuming that source and destination
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
