Bug 219946

Created attachment 104711 [details]
The entire /var/log directory

of course sax is not killing all servers. Calling test is always a risc
because multiple instances of X-Servers could crash the system
(bad X implementation ?)

does saving without testing work ?

Could you please describe how to reproduce this problem exactly? During installation? Afterwards? sax2 started on top of Xserver or from console? etc. Thanks.

Yes, according the bug subject: During installation, X configuration is detected and proposed. Runing the "test installation" offers to "Save the configuration" after a succesfull test (Like running SaX on running system does). So I did.

I guess, X configuration should not be offered to be saved because it is runinng in the installation workflow. The installation workflow itself should save the configuration after clicking [Next} in the hardware proposal dialog.

After that testing and clicking [Save] (or whatever), X server (installation in Qt) was killed.

BTW: if running the "test configuration" is a rict, user should be informed before running the test.

Still not sure, who killed whom. This needs to be investigated (and hopefully reproduced) by a YaST developer first.

This has been _reported_ by a YaST developer :)
What exactly do you need?

Created attachment 104887 [details]
bug219946.jpg, camera screenshot

Looks like the Save button is displayed still on the test Xserver. I don't think it matters if you chose there Save or Cancel. It seems there is no way back from the second Xserver to the first one after terminating the former. Instead the first Xserver crashes. Maybe Xorg.0.log.old is the correct logfile:

Backtrace:
0: Xorg(xf86SigHandler+0x81) [0x80c00b1]
1: [0xb7fdc420]
2: /usr/lib/xorg/modules/input//mouse_drv.so [0xb7c83072]
3: Xorg [0x80c022a]
4: Xorg [0x80aa441]
5: [0xb7fdc420]
6: Xorg(xf86UnblockSIGIO+0x57) [0x80a9e57]
7: Xorg [0x80b49dd]
8: Xorg(xf86EnterServerState+0x1f) [0x80b4a0f]
9: Xorg(xf86Wakeup+0x3de) [0x80c17ee]
10: Xorg(WakeupHandler+0x59) [0x808a279]
11: Xorg(WaitForSomething+0x1b9) [0x819aa29]
12: Xorg(Dispatch+0x82) [0x80861c2]
13: Xorg(main+0x495) [0x806e705]
14: /lib/libc.so.6(__libc_start_main+0xdc) [0xb7d6ef9c]
15: Xorg(FontFileCompleteXLFD+0x1e1) [0x806da21]

Marcus, please, reevaluate this issue.

It's an Xserver issue.

Can you reproduce this problem on an installed system? 

First configure a fbdev based Xserver with "sax2 -a -r -m 0=fbdev". On top of this Xserver start "sax2" *with* DISPLAY set. Then press the Test button to try to reproduce this problem. If it can be reproduced we could try to debug the Xserver on an installed system, which would help a lot. Debugging the Xserver in an installed system is way more complicated.

Hmm, now it says:
Your modifications will take effect the
next time the graphics system is
restarted. Exit SaX now?
[ Yes ] [ No ]

It doesn't offer to save the configuration :(

If I run X from the first console with `startx` and `sax2` from another console, it still opens SaX UI in the running X. It doesn't run any separate X.

Another case:
`startx` as nobody on console1
`sax2` as root on console2

Sax doesn't offer to save the configuration but operates as in the previous case "will take effect ... next time".

So the only way how to reproduce it is run the second stage installation again:
just `touch /var/lib/YaST2/runme_at_boot` and `restart`. I guess this could be somehow connected with some Marcus' "recently-WORKSFORME-closed" bug that talks about some blackout when the X are detected, see bug #219708.

I don't want to run SaX2 a second Xserver! Is it really so difficult to start "sax2" inside of a xterm?

No, it is not so difficult, this was the first case I've tried.
Sorry, that it wasn't obvious.

--- cut ---
Hmm, now it says:
Your modifications will take effect the
next time the graphics system is
restarted. Exit SaX now?
[ Yes ] [ No ]
--- cut ---

Ok. So it will be very difficult/nearly impossible to debug. This is bad.

*** Bug 216451 has been marked as a duplicate of this bug. ***

*** Bug 220199 has been marked as a duplicate of this bug. ***

Wow. I can easily reproduce this issue during installation and even afterwards when running SaX2 on top of a fbdev based Xserver.

Just started sax2 on a naked Xserver running in gdb. Result when pressing Save button on test Xserver is a crashed fbdev Xserver.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211565504 (LWP 8155)]
0x080d2109 in XisbBlockDuration (b=0x0, block_duration=-1) at xisb.c:178
178             b->block_duration = block_duration;
(gdb) #0  0x080d2109 in XisbBlockDuration (b=0x0, block_duration=-1) at xisb.c:178
#1  0xb7b7b072 in xf86MouseProtocolNameToID ()
   from /usr/lib/xorg/modules/input//mouse_drv.so
#2  0x080cc0aa in xf86SigioReadInput (fd=12, closure=0x8200de8)
    at xf86Events.c:1212
#3  0x080ad001 in xf86SIGIO (sig=29) at ./../shared/sigio.c:113
#4  <signal handler called>
#5  0xb7f30410 in ?? ()
#6  0xbff3e8f8 in ?? ()
#7  0x00000000 in ?? ()
(gdb) 

But this looks like a different problem to me !?!

I have had the same error during installation. Is there any
information/logfiles that I can send to help?
BTW The "test" of monitor/graphic card is very good to have during installation
so please do not remove it. At least I have had many problems of unknown
monitors or wrong v./h. sync freq. settings.

Best regards,
HJH

Null pointer reference. Where is pMse->buffer set? Not at all?

_X_EXPORT void
XisbBlockDuration (XISBuffer *b, int block_duration)
{
        b->block_duration = block_duration;
}

static void
MouseReadInput(InputInfoPtr pInfo)
{
    MouseDevPtr pMse;
    int j, buttons, dx, dy, dz, dw, baddata;
    int pBufP;
    int c;
    unsigned char *pBuf, u;


    pMse = pInfo->private;
    pBufP = pMse->protoBufTail;
    pBuf = pMse->protoBuf;

    /*
     * Set blocking to -1 on the first call because we know there is data to
     * read. Xisb automatically clears it after one successful read so that
     * succeeding reads are preceeded by a select with a 0 timeout to prevent
     * read from blocking indefinitely.
     */
    XisbBlockDuration(pMse->buffer, -1);

Egbert, Matthias. Could you have a look at this one, please? Looks like pMse/pInfo->private is not initialized correctly.

*** Bug 221592 has been marked as a duplicate of this bug. ***

Matthias will investigate.

The easiest way to reproduce is to start first Xserver with option
"-xf86config /etc/X11/xorg.conf.install" (fbdev based xorg.conf from installation), start "sax2 -r" on this Xserver, then click on 

  Ok --> Test --> Save

==> first fbdev based Xserver is crashing

*** Bug 221301 has been marked as a duplicate of this bug. ***

This bug is now mentioned as one of the most annoying bugs of Beta2:
--> http://en.opensuse.org/Bugs:Most_Annoying_Bugs

BTW, it would help us to know if this bugreport also occurs before Beta2. So if someone wants to test, please let us know, about your results. Thanks.

As you can see, I opened bug 216451 on the 30th of October, so long before beta2.

Thanks! Good to know.

Created attachment 106067 [details]
Workaround for this issue

+Patch6:         mouse-readinput.diff

 pushd xf86-input-mouse-*/src
 %patch3 -p6
+%patch6 -p2
 popd


This seems to be a rare race condition. It apparently only happens with PS/2 mice, and if you select the Save button on the test screen with the mouse (and not the keyboard).

It seems that if a mouse event is detected during VT switch MouseReadInput() is called while it wasn't allowed to do so. As typically a VT switch is induced by keyboard and not by mouse, this doesn't happen during regular work.

This patch does *not* fix the bug that MouseReadInput() shouldn't be called, but it now returns gracefully, if it *is* called while the mouse device isn't open.

Just want to say I am using a USB mouse, and it happens to me.

Principally the same code. Maybe the difference for me to be able to reproduce was the resolution :-]

This is a rare race condition, it's difficult to trigger. But it seems to be crashing reliably if you finally hit it ;)

Thanks. Fixed for RC1.

Guys, can you give the version of the fixed package, so that one can test when they become available?

Thanks.

Check for RPM changelog entry ("rpm --changelog -q xorg-x11-driver-input")

-------------------------------------------------------------------
Fri Nov 17 18:11:52 CET 2006 - sndirsch@suse.de

- mouse-readinput.diff:
  * fixed mouse driver crash (Bug #219946)

*** Bug 221649 has been marked as a duplicate of this bug. ***