Oleg.Malashenko's picture

On Debian/Etch all examples hang on startup

Project:The Open Toolkit library
Version:0.9.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:won't fix
Description

Hi,

I am using Debian/Etch r5 on i386 box with Mono-2.0.1

It appears that all of the examples hang in constructor of OpenTK.Platform.X11.X11XrandrDisplayDevice during XRRTimes call.
Further investigation shows that it hangs in _XLockDisplay(). Somehow display is already locked at that point. Note, that this is not because of XLockDisplay() call inside OpenTK code.

The regression is related to OpenTK-0.9.1 and to TRUNC too. On Debian/Lenny all works just fine.

If you need backtraces or something I will provide it.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

#1

Which Mono version does Debian/Lenny have?

Does the following code hang too? If not, the hang is probably due to a deadlock between OpenTK and Windows.Forms.

using System;
using OpenTK;
 
class Test : GameWindow
{
    public Test() : base(640, 480) { }
 
    public override void OnRenderFrame(RenderFrameEventArgs e)
    {
        GL.Clear(ClearBufferMask.ColorBufferBit);
        SwapBuffers();
    }
 
    public static void Main()
    {
         using (Test t = new Test())
         {
              t.Run();
         }
    }
}
Oleg.Malashenko's picture

#2

On Debian/Lenny I am using the same Mono version as on Debian/Etch (Mono-2.0.1, built from sources).

Provided test hangs on Etch and works on Lenny.

the Fiddler's picture

#3

Which Xorg versions is each OS using? There's a good chance OpenTK is misusing XLockDisplay() and/or fails to enable multithreaded X.

I will install Lenny and see if I can reproduce the issue.

Oleg.Malashenko's picture

#4

I have already tried to find out if OpenTK calls XLockDisplay in unsafe manner but it actually doesn't call XLockDisplay directly during init. _XLockDisplay is called from insides of libX11 and folks.

Tomorrow I will try to get all backtraces for _XLockDisplay and _XUnlockDisplay for your example. I hope, there will be not so many of them as in examples provided with OpenTK distribution :)

Etch xserver-xorg-core 1.1.1
Lenny xserver-xorg-core 1.4.2

Oleg.Malashenko's picture

#5

Hi

I have wrote 2 simple examples that do the following:
XInitThreads
XOpenDisplay
XDefaultScreen
XRRTimes
XCloseDisplay

First in C++, second in C#. C++ code works perferctly on all platforms, while C# code hangs while second (recursive) _XLockDisplay call inside XRRTimes.

I tried to call XLockDisplay several times from C# code, but it works as it should (doesn't hang).
There should be a difference between C++ and Mono call to XRRTimes , but I don't have a faitnest idea of a reason :(

In attach you can find source for both examples.

Breakpoint 2, _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
485     ../../src/locking.c: No such file or directory.
        in ../../src/locking.c
(gdb) bt
#0  _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
#1  0xb7fe1b1a in XRRTimes (dpy=0x8353e48, screen=0, config_timestamp=0xbfecb524) at ../../src/Xrandr.c:321
(gdb) c
Continuing.
 
Breakpoint 2, _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
485     in ../../src/locking.c
(gdb) bt
#0  _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
#1  0xb730ee36 in XQueryExtension (dpy=0x8353e48, name=0xb7fe2188 "RANDR", major_opcode=0xbfecb3d0, first_event=0xbfecb3d4, 
    first_error=0xbfecb3d8) at ../../src/QuExt.c:46
#2  0xb730360b in XInitExtension (dpy=0x8353e48, name=0xb7fe2188 "RANDR") at ../../src/InitExt.c:49
#3  0xb72d6ea3 in XextAddDisplay () from /usr/lib/libXext.so.6
#4  0xb7fe0f29 in XRRFindDisplay (dpy=0x8353e48) at ../../src/Xrandr.c:139
#5  0xb7fe1aa7 in _XRRValidateCache (dpy=0x832fd10, screen=137707080) at ../../src/Xrandr.c:242
#6  0xb7fe1b24 in XRRTimes (dpy=0x8353e48, screen=0, config_timestamp=0xbfecb524) at ../../src/Xrandr.c:322
Oleg.Malashenko's picture

#6

Attach

AttachmentSize
examples.tgz1019 bytes
Oleg.Malashenko's picture

#7

I screwed up a little with my C++ test :)

Compiled and linked with -pthread it hangs too :)
So, the problem is totally out of OpenTK scope.

Thank you.

the Fiddler's picture

#8

Thanks for the test cases, it has helped identify a possible error in the XRRTimes signature:

    [DllImport("libXrandr", EntryPoint = "XRRTimes")]
    public static extern System.UInt32 XRRTimes(System.IntPtr dpy, int screen, out int config_timestamp);

should be

    [DllImport("libXrandr", EntryPoint = "XRRTimes")]
    public static extern System.UInt32 XRRTimes(System.IntPtr dpy, int screen, out IntPtr config_timestamp);

because the config_timestamp is an unsigned long. Indeed, your C# test segfaults with the first signature (archlinux amd64).

Is your Lenny amd64?

Edit: I cannot get the C++ example to crash, with or without pthread.

Oleg.Malashenko's picture

#9

Maybe I was not clear enough in my first message (sorry for confusing you), but the bug appears on Etch/i386 with Mono-2.0.1 built from sources.
On Lenny/i386 bug doesn't appear and all examples and test cases doesn't fail.
I am almost sure that this is a bug in libXrandr.so (or bad compiler/linker flags)

If you want to make sure that tests fail use Debian/Etch i386 and attached c++ example (makefile included)

BTW, I copypasted XRRTimes signature from opentk-0.9.1 release so maybe you should fix it in TRUNK too.

AttachmentSize
xrandr_test.tgz1.29 KB
the Fiddler's picture

#10

My mistake, I should have paid more attention to the OP. I am installing an etch virtual machine and will forward the bug to Debian if it appears there, too.

I'm testing the new signature and I'll push it to trunk if it doesn't cause any problems.