Re: Shared memory - Was: 2 Queries
On Wed, 1 Mar 2000, Christopher Masto wrote: On Wed, Mar 01, 2000 at 11:28:13AM -0800, John Polstra wrote: It takes no more than a well-designed operating system service to ensure that badly written programs don't fail to release resources when they crash. We didn't design that particular service. That's why it's called System V shared memory. I did mean to imply that it was poorly designed, but not that it was designed by FreeBSD's designers. Also, it's persistent for legitimate design reasons, just like files are. Applications need to clean up after themselves. You can have many more than 32 files. Files are (usually) well-organized and have names, so you can wipe out your web browser's cache or lock file relatively easily. Files take up a negligible fraction of the available file space. SysV shared memory is limited, unnamed, unorganized, and uses up a very scarce resource. The OS has no way of knowing whether an application wants its shared memory segments to survive after it terminates. That's unfortunate. That's one of the reasons I try to stay away from SysV IPC. I don't like to have to reboot. You don't have to reboot. Ipcrm is you friend. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
In any case, one major offender is imlib. Since I've recently gone
Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option
or things would go bad after a few minutes or hours of use.
That explains the errors when running xchat, but that doesnt explain
Netscape ;)
The annoying thing about this is that if a program decides to die because
of this error, it seems I've got a 50/50 chance that it's taken out for
good. I have to reboot to reclaim memory :(
It'd be nice if we had a utility that could clean out and reclaim the
shared memory in 1 swoop. Then we'd be able to shut down XFree86 (and
obviously any other apps using shared memory), and get on with life :)
(anyone listening?)
Cliff Rowley
- while (!asleep) { code(); }
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 03:57:19PM -0600, Ade Lovett wrote: On Tue, Feb 29, 2000 at 01:41:43PM -0500, Christopher Masto wrote: In any case, one major offender is imlib. Since I've recently gone Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option or things would go bad after a few minutes or hours of use. Can you expand a bit on "go bad"? I have a couple of machines here running with GNOME for days on end with no shared memory problems. Title bars in sawmill suddenly turning black, GNOME pixmaps disappearing/getting corrupted, that sort of thing. I'm not seeing any leaks, though: [...] Shared Memory: T ID KEYMODE OWNERGROUP SEGSZ CPID LPID m 655362622055 --rw-r--r-- rootwheel 1048576298298 m 41615362 792064 --rw-rw-rw- adestaff 4 12549 12549 Funny, I even have the option turned off and I've still got: chris@lion-around:~$ ipcs -bpm Shared Memory: T ID KEYMODE OWNERGROUP SEGSZ CPID LPID m 655365432010 --rwa--pgsqlpgsql120204204 m 655375432001 --rw---pgsqlpgsql 1063936204204 m 655385432007 --rw---pgsqlpgsql 96424204204 m 196611 0 --rw-r--r-- rootwheel 4096837 53838 m 131076 0 --rw-r--r-- rootwheel 4096837 55434 m 3211269 0 --rwarwarwachrischris 1420800 41206 41206 m 1310726 0 --rw-r--r-- rootwheel 4096837 55429 m 1310727 0 --rwarwarwachrischris 65536934837 m 131080 0 --rw-r--r-- rootwheel 4096837926 m 131081 0 --rwarwarwachrischris 65536934837 m 131082 0 --rwarwarwachrischris 65536934837 m 196619 0 --rw-r--r-- rootwheel 4096837934 Still, it's not just me. Several friends have come to me after my recommendation that they try sawmill+GNOME with the complaint that their title bars were getting messed up, and turning of MIT-SHM solved it. One is running -current, another is running 3.4-RELEASE. And I've heard the same thing on the mailing lists. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, 1 Mar 2000, Alfred Perlstein wrote: I used to have a shell script to do this, but i don't know where it went. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] I do! (line is wrapped) #!/bin/sh ipcs | sed "s/[ ][ ]*/ /g" | cut -f 2 -d" " | sed "s/[^0-9]//g" | xargs -t -n 1 ipcrm -m To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 11:54:35AM -0500, Adam wrote:
#!/bin/sh
ipcs | sed "s/[ ][ ]*/ /g" | cut -f 2 -d" " | sed
"s/[^0-9]//g" | xargs -t -n 1 ipcrm -m
Always with the sed. ipcrm `ipcs -m | awk '$1 == "m" { print "-m " $2 }'`
anyone?
--
Christopher Masto Senior Network Monkey NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net
Free yourself, free your machine, free the daemon -- http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 01:41:43PM -0500, Christopher Masto wrote: Personally, I have this extreme distaste for sysv shared memory. It is a very scarce resource that is not freed automatically, and seems to go completely against the unix model. Reminds me of having to free memory on the Amiga, and slowly running out of chip RAM. In any case, one major offender is imlib. Since I've recently gone Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option or things would go bad after a few minutes or hours of use. I would say that the programs you've mentioned are badly written then. It takes no more than XSync(disp,False); shmctl( shmid, IPC_RMID, 0); right after a call to XShmAttach() for a shared memory image to achieve the automatic reclamation of the memory. Shared pixmaps are different, but not that many programs should use these anyway. Cheers, -- Anton Berezin [EMAIL PROTECTED] The Protein Laboratory, University of Copenhagen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 06:20:28PM +0100, Anton Berezin wrote: I would say that the programs you've mentioned are badly written then. It takes no more than XSync(disp,False); shmctl( shmid, IPC_RMID, 0); It takes no more than a well-designed operating system service to ensure that badly written programs don't fail to release resources when they crash. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 07:58:34AM -0800, Alfred Perlstein wrote:
It'd be nice if we had a utility that could clean out and reclaim the
shared memory in 1 swoop. Then we'd be able to shut down XFree86 (and
obviously any other apps using shared memory), and get on with life :)
(anyone listening?)
er, yes this is entirely possible.
If you want to clear SHM then use 'ipcs' to list and 'ipcrm' to delete.
I used to have a shell script to do this, but i don't know where it
went.
Hi, I dont' know if this meet what you described, but I use a single line
to clean un-referenced shared memory.
x.sh:
#!/bin/sh
ipcs | awk '{if ($5 == ENVIRON["USER"]) system("ipcrm -m" $2)}'
Before applying 3 options posted by ade lovett into my kernel,
most heavy gtk programs like xmms, gimp, gnome-controlcenter...etc,
will die with whole X crashing. (I invoke X with gnome-session, what the
gnome document said) Thus I have to run x.sh whenever my X crashed with
share memory bodiz *shurg* /.\
--
CirX - This site doesnt' exist.
9c k9o h9 s1bg s1f, 7v .y xqx a sj m8r ffg1 vg5 a6 asox tmul h38.
ant sj m8r ob ? 1fj mwby a1 tao vg5. soq df v' .a. CirX.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, 1 Mar 2000 12:46:13 -0500, Christopher Masto [EMAIL PROTECTED] said: It takes no more than a well-designed operating system service to ensure that badly written programs don't fail to release resources when they crash. Unfortunately, the System V shared-memory API is brain-damaged and does not permit this. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 11:28:13AM -0800, John Polstra wrote: It takes no more than a well-designed operating system service to ensure that badly written programs don't fail to release resources when they crash. We didn't design that particular service. That's why it's called System V shared memory. I did mean to imply that it was poorly designed, but not that it was designed by FreeBSD's designers. Also, it's persistent for legitimate design reasons, just like files are. Applications need to clean up after themselves. You can have many more than 32 files. Files are (usually) well-organized and have names, so you can wipe out your web browser's cache or lock file relatively easily. Files take up a negligible fraction of the available file space. SysV shared memory is limited, unnamed, unorganized, and uses up a very scarce resource. The OS has no way of knowing whether an application wants its shared memory segments to survive after it terminates. That's unfortunate. That's one of the reasons I try to stay away from SysV IPC. I don't like to have to reboot. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Wed, Mar 01, 2000 at 02:57:38PM -0500, Christopher Masto wrote: Also, it's persistent for legitimate design reasons, just like files are. Applications need to clean up after themselves. You can have many more than 32 files. Files are (usually) well-organized and have names, so you can wipe out your web browser's cache or lock file relatively easily. Files take up a negligible fraction of the available file space. That limitation is FreeBSDs fault and is correctable in the kernel config file so it's really the administrator's fault. For instance the default on a recent Irix machine is 600 segments which a maximum size of 512MB each. Solaris has nearly as many. SysV shared memory is limited, unnamed, unorganized, and uses up a very scarce resource. Keys provide a limited sort of naming. It's not hierarchical, but it basicaly gives you 2^32 names which can be accessed exclusivly. The resource is only as scarce as the system admin makes it. I don't like FreeBSD's default limits, but they are just that, defaults. The OS has no way of knowing whether an application wants its shared memory segments to survive after it terminates. That's unfortunate. That's one of the reasons I try to stay away from SysV IPC. I don't like to have to reboot. It would be nice if SysV IPC had a refrence counting mode (though anyone who what they were doing could implement such a thing with a semaphore to do the refcounting which is probalby why they didn't do it). The fact is though, there are significant cases where the OS *cannot* know if the application is done or not. SysV shm is really designed (as far as I can tell) to be a low level API, somewhere around the level of malloc. It's not a complete solution and that's the trap people keep falling into. You have to implement that goop to go around it. It's not really that hard and most of it is write once, use over and over again. If you use ipcrm you don't have to reboot. I've spent the last couple weeks hacking on some code which uses SysV shared memory and semaphores. It's really not that bad. You just have to get into the proper mindset. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
In message [EMAIL PROTECTED], Christopher Masto writes: SysV shared memory is limited, unnamed, unorganized, and uses up a very scarce resource. You know, you should go back in the archives to when sysV IPC was released, and you will be able to find some *really* nasty but technically competent critizisms of it. You are preaching to a very seasoned choir here... -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Shared memory - Was: 2 Queries
Just an update on this shared memory error. After running XFree86 for a
couple of hours, running various programs (I've not seen a pattern yet):
[dozprompt@guru]# xchat
Gdk-ERROR **: BadAccess (attempt to access private resource denied)
serial 84 error_code 10 request_code 142 minor_code 1
Gdk-ERROR **: BadShmSeg (invalid shared segment parameter)
serial 85 error_code 151 request_code 142 minor_code 5
Reckon this is due to a work in progress on the SYSV* section of the
kernel? Anyone know if that is being worked on right now?
Cliff Rowley
- while (!asleep) { code(); }
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
More likely work in progress with broken gtk desktop voodoo. Dont you think that would be bit of a cooincidence? Since the messages are almost identical in nature to the ones I've been getting from other programs *not* gtk/gdk based ;) The link between them so far is shared memory... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 09:57:48AM +, Cliff Rowley wrote: More likely work in progress with broken gtk desktop voodoo. Dont you think that would be bit of a cooincidence? Since the messages are almost identical in nature to the ones I've been getting from other programs *not* gtk/gdk based ;) The link between them so far is shared memory... Personally, I have this extreme distaste for sysv shared memory. It is a very scarce resource that is not freed automatically, and seems to go completely against the unix model. Reminds me of having to free memory on the Amiga, and slowly running out of chip RAM. In any case, one major offender is imlib. Since I've recently gone Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option or things would go bad after a few minutes or hours of use. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
: are almost identical in nature to the ones I've been getting from other : programs *not* gtk/gdk based ;) The link between them so far is shared : memory... : :Personally, I have this extreme distaste for sysv shared memory. It :is a very scarce resource that is not freed automatically, and seems :to go completely against the unix model. Reminds me of having to free :memory on the Amiga, and slowly running out of chip RAM. : :In any case, one major offender is imlib. Since I've recently gone :Gnome, I've had to turn off imlib's "MIT-SHM shared memory" option :or things would go bad after a few minutes or hours of use. :-- :Christopher Masto Senior Network Monkey NetMonger Communications :[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net : :Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ Maybe we can convince them / submit patches to use mmap() based shared memory (file-backed), which we can now do efficiently with the MAP_NOSYNC option. I have a love-hate relationship with SysV shared memory. On the one hand it is virtually guarenteed to work across all UNIX platforms. On the otherhand most platforms have absurd resource limitations applied to SysV shared memory calls. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, 29 Feb 2000 10:47:33 -0800 (PST), Matthew Dillon [EMAIL PROTECTED] said: Maybe we can convince them / submit patches to use mmap() based shared memory (file-backed), which we can now do efficiently with the MAP_NOSYNC option. Even better would be POSIX shared memory. It wouldn't be too hard to have the shm_open() syscall set a file flag which mmap() would them look at to conditionally set MAP_NOSYNC on its own. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Shared memory - Was: 2 Queries
On Tue, Feb 29, 2000 at 08:08:45PM +, Cliff Rowley wrote: It'd be nice if we had a utility that could clean out and reclaim the shared memory in 1 swoop. Then we'd be able to shut down XFree86 (and obviously any other apps using shared memory), and get on with life :) Uh.. ipcrm? The problem is that I always end up taking something out that's in use.. or intentionally left around unattached, so it just _looks_ like it's not in use. I think imlib does this as some sort of cache (ugh!). Then I experience a variety of even more annoying random behavior. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
