The eciadsl-synch program leaves a semaphore every time it's run. If you run it enough times, you can reach the maximum number of allowed semaphores in the system. E.g. this problem can be exploited using the eciadsl-probe-synch with a lot of synch binary files. Reproducible: Always Steps to Reproduce: 1. run ipcs -s 2. run eciadsl-synch 3. run ipcs -s and compare with previous output: there is one more semaphore in the table! Actual Results: ipcs shows that there is one more open semaphore. But the program eciadsl-synch has ended! Expected Results: The created semaphores should be destroyed when the program ends. The package was installed to let a Zyxel PRestige 630 ADSL modem work. The package was taken from the stable tree: it's version 0.10. # emerge info Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.1 4-gentoo-r2 i686) ================================================================= System uname: 2.6.14-gentoo-r2 i686 Celeron (Covington) Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X1 1/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.mcs.anl.gov/pub/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="aalib acl acpi adns alsa apache2 apm arts bash-completion bcmath berkdb bit map-fonts bzip2 cdparanoia cdr crypt cscope cups curl dbm dvd dvdr eds emacs emb oss encode ethereal expat foomaticdb fortran ftp gdbm gmp gnutls gpm gstreamer i conv ipv6 java libg++ libwww maildir mbox mcal mhash mime mmx motif mp3 ncurses nls ogg oss pam pcntl pcre pdflib perl php posix ppds python readline recode sam ba sasl scanner sharedmem slang sockets socks5 spell ssl sysvipc tcltk tcpd thre ads tiff truetype-fonts type1-fonts udev unicode usb vorbis wifi x86 xinetd xml xml2 xmms zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVER LAY
does version 0.11 fix this?
(In reply to comment #1) > does version 0.11 fix this? I don't know... I just emerged the `stable' version of the globespan-adsl package and found this problem.
please try the 'unstable' version to see if it solves the problem.
(In reply to comment #3) > please try the 'unstable' version to see if it solves the problem. I emerged version 0.11. eciadsl-synch now leaves no stale semaphores, but couples of shared memory areas! They can be listed with the command "ipcs -m". So the problem isn't fixed but kind of moved! :-\ I found another little bug in the latest version: the eciadsl-probe-synch, at line 81, incorrectly sets the BIN_DIR variable to "/usr/local/bin", while it should be "/usr/bin"
let me get this straight. every time you run eciadsl-synch it creates a new shared memory zone? if you run for lets say 3 times, you end up with 3 new shared areas?
(In reply to comment #5) > let me get this straight. every time you run eciadsl-synch it creates a new > shared memory zone? if you run for lets say 3 times, you end up with 3 new > shared areas? Actually 6 shared memory areas: 2 for each run.
Please check if version 0.12 still has this problem.
(In reply to comment #7) > Please check if version 0.12 still has this problem. Sorry, I switched to an ethernet modem right after I found this problem. Now I can't find the USB modem, so I can't check if the new driver works. :-( Anyway, I admire your dedication to this cause... I almost forgot I opened this bug in the end of 2005!
It is on my open bug list, so it is hard to miss :) Closed with TEST-REQUEST resolution until someone having the hardware reopens it ... or confirms the problem is gone.