GNOME Bugzilla – Bug 102058
shared memory doesn't work on Darwin
Last modified: 2004-01-08 14:42:18 UTC
GIMP fails to load everything apart xcfs, most filters misrender too (I get a black screen most of the time). If run with --no-shm, everything works. I get a lot of these errors on the console too, don't know if it's related: *** malloc[24479]: Deallocation of a pointer not malloced: 0xf265; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
I too have the same problem with Gimp and OSX.
Apparently this also happens with Gimp 1.2.3. We should try to fix this for 1.2.4 IMHO.
Setting the target milestone to 1.2.4, as per Simon's suggestion. Some contributions from MacOS users and developers would be more than welcome...
How can we fix this if we have no idea what is going wrong? We can only fix it if we get some debugging help here and even if we find a fix, we should be very careful to apply it to the 1.2 tree. This should only happen if the fix is trivial and fixing this problem is definitely not a requirement for the 1.2.4 release. Setting the target milestone to 1.3.x for that reason.
I don't think your shm will ever work well on OS X. I assume you are using sys v shared memory - OS X by default has a very small sysv shared memory allocation, which you are likely to hit quickly. <looks at the source> It looks like you are using SysV shm with shmat(). I think POSIX shm works better on OS X, and definitely mmap works fine. POSIX shm is more standard than sysv shm anyway, so you should probably switch. btw, you can increase your sysv shm allocations on OS X by editing the sysctls in the file: /System/Library/StartupItems/SystemTuning/SystemTuning. But this would only be acceptable for testing purposes, its not a fix for gimp. :) in summary, GIMP should use POSIX shm on OS X, or mmap. -Ben (fink developer)
argh, stupid safari didn't put in line breaks, Sorry about that, blame Apple. :)
POSIX shm is far from universal. Linux only has it with glibc 2.2 or greater, and kernel 2.4. It's part of POSIX.1b, which is something a lot of older unixes don't implement. Ideally, we should move towards a full mmap based solution, but that is post-1.4 material. It doesn't look that difficult to put a POSIX shm implementation in the current code, so that could be done in HEAD. It should be a configure option (--enable-posix-shm) that isn't on by default, except perhaps on OS X. I wonder what the rationale Apple had for putting this limitation on SysV shm.
Ok, maybe we should just add a hack into the configure script for 1.2.4 to disable shared memory on OS X. So unsuspecting users would not get trapped by this limitation by Apple.
Well, I wouldn't be opposed to backporting the changes to HEAD to 1.2 once they are done. They'd only affect OS X users and if it didn't work properly, well, they were doing --no-shm anyway. We'd want the configure script special casing in either case, so may as well do what Simon suggested now. I don't consider this working shm a blocker for 1.2.4.
This has been addressed in 1.2 and HEAD: 2003-01-13 Manish Singh <yosh@gimp.org> * configure.in: Partially address #102058 with a --with-shm configure options. Defaults to sysv except on OS X, where it is none.
Hm, I heard that OS X 10.2 doesn't have this issue anymore. Can anyone confirm or deny this?
I'm using 10.2.3 and still get this.
I guess the OS X server dist has it tuned up, otherwise Oracle won't run. I wonder if you can query the allocation size somehow...
SysV shm is available in Mac OS X 10.1, but is severely limited; the hardcoded systemwide shared region count and max total shared memory are too small to be useful. On Mac OS X 10.2, the SysV shm limits are sysctl parameters, so it's possible to increase them to useful levels. kern.sysv.shmmax: 4194304 kern.sysv.shmmin: 1 kern.sysv.shmmni: 32 kern.sysv.shmseg: 8 kern.sysv.shmall: 1024
Downgrading severity, 1.2.x and 1.3.x both default to shm off on MacOS X. If someone wants to implement a transport over mmap or POSIX shm feel free.
I am afraid this won't necessarily happen before 2.0. We could target it for 2.0.1 or decide to postpone it to 2.2. Or is someone working on this?
Well this was rather trivial, I'm surprised no OS X person stepped up to the task. 2003-12-27 Manish Singh <yosh@gimp.org> * app/main.c * app/plug-in/plug-in-shm.c * libgimp/gimp.c: POSIX shared memory tile transport implementation, and a little code cleanup of the SysV and Win32 implementations. * configure.in: checks for shm_open, default to POSIX shared memory transport on OS X.
I'd like an OS X user to confirm this works before closing the bug.
I plan to build this on Mac OS 10.3 today.
Sven: did it work?
Sorry, but I didn't get around to build it. People that promised me an account didn't show up until the event was almost over so it just didn't happen :(
The issue is apparently resolved with the build I did this morning of GIMP 2.0pre1 on Mac OS X 10.3.