Hello all, First, happy to see the new release of WINE 20050111 for FreeBSD (and previous 20041201) I obtained and compiled the latest version for my standard FreeBSD 5.3 install. ? Upon running any windows/wine app I get the error messages err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not available err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not available err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! Some apps (if they do not use the heap) continue to run, the apps I want to use (MS Office 2000 - Word/Excel/PowerPoint) fail as follows: ------------------------ MS Word will display the splash screen and then a message box with "There is not enough memory or disk space to run Word." before crashing ------------------------ MS Excel will start with the message box "Cannot use object linking and embedding" before starting, but attempting use excel will result in an out of memory error and then a crash ------------------------ MS PowerPoint doesn't even start. ------------------------ This is dissapointing, we have managed (http://caia.swin.edu.au/reports/041129A) to install MS Office 2K on WINE 20040505 under FreeBSD but were hoping that this newer version would fix our two discovered problems (the new file.. dialog and the pulldown menus if more than one office app is running). Unfortunately, it seems that the new version breaks everything. Further pottering around found... HEAP_CreateSystemHeap() calls MapViewOfFileEx() which calls NtMapViewOfSection() which calls map_view() which attempts a normal allocation - wine_mmap_is_in_reserved_area() == 0 calling wine_anon_mmap() The returned pointer is valid so wine_anon_mmap() succeeds BUT the returned ptr != base and so the function returns STATUS_CONFLICTING_ADDRESSES which returns up the chain and the heap allocation fails. On my system base being requested is 0x80000000 and ptr being returned is 0x9996d000. ?This result then fails the is_beyond_limit() test... Any clues would help!! Thanks. Jason
Hello all, First, happy to see the new release of WINE 20050111 for FreeBSD (and previous 20041201) I obtained and compiled the latest version for my standard FreeBSD 5.3 install. ? Upon running any windows/wine app I get the error messages err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not available err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not available err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! err:heap:HEAP_GetPtr Invalid heap 0x0! Some apps (if they do not use the heap) continue to run, the apps I want to use (MS Office 2000 - Word/Excel/PowerPoint) fail as follows: ------------------------ MS Word will display the splash screen and then a message box with "There is not enough memory or disk space to run Word." before crashing ------------------------ MS Excel will start with the message box "Cannot use object linking and embedding" before starting, but attempting use excel will result in an out of memory error and then a crash ------------------------ MS PowerPoint doesn't even start. ------------------------ This is dissapointing, we have managed (http://caia.swin.edu.au/reports/041129A) to install MS Office 2K on WINE 20040505 under FreeBSD but were hoping that this newer version would fix our two discovered problems (the new file.. dialog and the pulldown menus if more than one office app is running). Unfortunately, it seems that the new version breaks everything. Further pottering around found... HEAP_CreateSystemHeap() calls MapViewOfFileEx() which calls NtMapViewOfSection() which calls map_view() which attempts a normal allocation - wine_mmap_is_in_reserved_area() == 0 calling wine_anon_mmap() The returned pointer is valid so wine_anon_mmap() succeeds BUT the returned ptr != base and so the function returns STATUS_CONFLICTING_ADDRESSES which returns up the chain and the heap allocation fails. On my system base being requested is 0x80000000 and ptr being returned is 0x9996d000. ?This result then fails the is_beyond_limit() test... Any clues would help!! Thanks. Jason
On Fri, 14 Jan 2005 16:21:44 +1100, Jason But wrote:> Hello all, > > First, happy to see the new release of WINE 20050111 for FreeBSD (and previous > 20041201) > > I obtained and compiled the latest version for my standard FreeBSD 5.3 > install. ?http://lists.freebsd.org/pipermail/freebsd-bugs/2004-October/009834.html I'd talk to Anish Mistry about it. This is a FreeBSD VM bug and I'm afraid you may have to patch your kernel (or use the freebsd ports which i believe patch out the code that breaks freebsd) thanks -mike
Mike,>> Hello all, >> >> First, happy to see the new release of WINE 20050111 for FreeBSD (andprevious>> 20041201) >> >> I obtained and compiled the latest version for my standard FreeBSD 5.3 >> install. ?> http://lists.freebsd.org/pipermail/freebsd-bugs/2004-October/009834.html> I'd talk to Anish Mistry about it. This is a FreeBSD VM bug and I'm afraid > you may have to patch your kernel (or use the freebsd ports which i > believe patch out the code that breaks freebsd)Mike, I have found this and a few other references to the problem. Some suggest that the kernel patch is required, others that it is no longer required for FreeBSD. Some have tried both ways and not fixed the problem. I haven't had time to patch the kernel or try this yet. Gerald Pfefifer suggests to me to try a couple of things and provide him with feedback: Will post results when I do this later in the week. Jason ------------------------------------------------------------------------------- If you want to give it a try, there are two things you could change in libs/wine/mmap.c, where there currently is specific code for FreeBSD. 1) #ifdef __FreeBSD__ /* Even FreeBSD 5.3 does not properly support NULL here. */ if( start == NULL ) start = (void *)0x110000; #endif Does anything change/improve if you reduce 0x110000? 2) void mmap_init(void) { struct reserved_area *area; struct list *ptr; #if defined(__i386__) && !defined(__FreeBSD__) /* commented out until FreeBSD gets fixed */ Does anything change/improve if you remove the "&& !defined(__FreeBSD__)"?