Re: Proposing a debugging method for this bug
Jérôme Marant wrote:
<snip/>
I ran a lot of them and I could switch back and forth from vt1 to vt7. Nothing
crashed at all.
BTW, Looking at the strace output, the problem could come from signal usage,
like you said.
Jerome, thanks for testing: the idea i got is that DFB is not
responsable for crashes on AMD64, and the crash happens because of the
special meaning SIGUSR1/2 have for cdebconf (whose signal handling
mechanism seems to be, BTW, buggy).
Back at extremadura i talked with Denis Oliver Knopp about how unsafe
was using two so popular signals like SIGUSR1/2 for VT switching and
this cdebconf-DFB interation does exploit the issue.
In DFB 1.0-rc2 DOK used for VT switching less common signals [1]:
/*
* FIXME: the following looks like a bad hack.
*
* SIGUNUSED is no longer unused, but is defined for backwards
compatibility.
* sparc, mips and alpha signal.h however do not define SIGUNUSED.
*/
#ifdef SIGUNUSED
#define SIG_SWITCH_FROM (SIGUNUSED + 10)
#define SIG_SWITCH_TO (SIGUNUSED + 11)
#else
#define SIG_SWITCH_FROM (31 + 10)
#define SIG_SWITCH_TO (31 + 11)
#endif
...
sigaction( SIG_SWITCH_FROM, &dfb_vt->sig_usr1, NULL );
sigaction( SIG_SWITCH_TO, &dfb_vt->sig_usr2, NULL );
...
Jerome, if i provide a simple patch for DFB 0.9.25, could you please
rebuild the libdirectfb-udeb and see if the crash is fixed?
In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25:
would this be possible if fixes this chash?
Using different signals for cdebconf db saving and DFB vt switching is
good, but still cdebconf's signal handling mechanism may need to be fixed.
cheers
Attilio
[1]
http://www.directfb.org/index.php/viewcvs.cgi/DirectFB/systems/fbdev/vt.c.diff?r1=1.5&r2=1.6
Reply to: