Your message dated Sat, 28 Sep 2013 01:54:39 +0200 with message-id <[email protected]> and subject line races galore in wmaker signal handling (segfaults) has caused the Debian Bug report #89514, regarding races galore in wmaker signal handling (segfaults) to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 89514: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=89514 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: wmaker Version: 0.61.1-4 Severity: normal Summary: guys who had written wmaker signal handlers need to be bashed with Stevens until the clue gets in. a) You can't call malloc(3) from the handler. b) You can't modify linked lists that are also modified from the main code, unless main code blocks signals in critical areas. Both rules are violated in wmaker. All versions, up to the current one from upstream CVS. As the result, wmaker merrily segfaults if signals happen in the wrong time (usually upon exit when we get a lot of SIGCHLD, but it's just a matter of probability), For 0.61.1-4: * src/startup.c::handleSig() contains the following: if (!WDelayedActionSet) { WDelayedActionSet = 1; WMAddIdleHandler(delayedAction, NULL); } WMAddIdleHandler() starts with calling malloc(). 'Nuff said. Instant segfault if SIGCHLD comes in the middle of malloc(). Observed in the wild. * Same code contains another race: WMAddIdleHandler() adds an entry into the linked list. Quite possibly right in the middle of manipulations with the same list (see WINGs/wevent.c). Our motto is "Segfaults Now"... * handleSig() again, look at the WCHANGE_STATE(). Think how much good it does if signal comes when main code is going to do WCHANGE_STATE() itself. I don't see how to fix it without changes to wevent.c API. We could preallocate structure for delayed action handler so that handleSig() wouldn't have to allocate anything, but then we need a new function (WMAddPreallocedHandler()). List manipulations outside of the handleSig() probably need to be protected by blocking SIGCHLD, but it can be too costly if we touch these lists often enough. WCHANGE_STATE() either needs callers to block signals, or (more likely) should be eliminated from handleSig() in favour of some sort of delayed handling a-la SIGCHLD. Code is in bad need of audit for potential races - authors had demonstrated complete lack of clue in writing async code. Sigh...
--- End Message ---
--- Begin Message ---Hi, this bug is very old. The curren wmaker version (0.95.5) doesn't have segfauls, and the window manager runs without problems. Please, if you know how to reproduce a bug about this problem, then reopen this bug. Thanks a lot. kix -- .''`. Rodolfo García Peñas (kix) <[email protected]> : :' : Proud Debian Developer `. `'` 4096R / 3F48 0B8C C385 AD41 9E28 006A 7B1F 5490 72B7 4923 `- Debian - when you have better things to do than fixing systems
--- End Message ---
