| | [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]
STR #1806
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Unassigned |
|---|
| Summary: | Fails to work under "wine" under "Linux" when compiled with MingW32 |
|---|
| Version: | 2.0-current |
|---|
| Created By: | khc |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| In both r5940 and r5941 the file src/win32/list_fonts.cxx a function
call is made to EnumFontFamiliesExW with a NULL argument where
there should be a pointer. Under "wine" under Linux, this NULL
pointer gets dereferenced and causes an illegal memory reference error.
Under MS Windows XP the cross-complied .exe files work all right.
Either MS Windows XP checks for the null pointer and fixes the call,
or the path using this call is not exercised.
The patch below fixes this, but then another memory reference error
occurs in another place in the code -- this time in the threading
part. I have not found a fix for the next level of error, except to
not run under wine :(.
> diff -c list_fonts.cxx~ list_fonts.cxx
*** list_fonts.cxx~ 2006-12-12 18:55:45.000000000 -0600
--- list_fonts.cxx 2007-10-10 10:27:18.000000000 -0500
***************
*** 172,178 ****
HDC dc = getDC();
if (has_unicode()) {
! EnumFontFamiliesExW(dc, NULL, (FONTENUMPROCW)enumcbW, 0, 0);
} else {
LOGFONT lf;
memset(&lf, 0, sizeof(lf));
--- 172,184 ----
HDC dc = getDC();
if (has_unicode()) {
! /* EnumFontFamiliesExW(dc, NULL, (FONTENUMPROCW)enumcbW, 0, 0);*/
! /*khc - 10oct07: NULL above causes zero pointer dereference in
! windows routines. So replace statement above with those below.*/
! tagLOGFONTW lf;
! memset(&lf, 0, sizeof(lf));
! lf.lfCharSet = DEFAULT_CHARSET;
! EnumFontFamiliesExW(dc, &lf, (FONTENUMPROCW)enumcbW, 0, 0);
} else {
LOGFONT lf;
memset(&lf, 0, sizeof(lf)); | |
| |
| #2 | spitzak
13:23 Oct 17, 2007 |
| I checked in something very similar to your fix, but it is not tested yet as I don't have access to a Windows machine.
Comparing to the code on the other side of the else statement, it certainly looks like a fix is needed. It is possible that this does not crash on Windows because has_unicode() is false on all the machines it has been tested on (only a few programs call list_fonts) | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
