wine XShm problem on remote display
Hello all, I am working on a vst (audio-plugin-)server with embedded linux. Everything is up and running in a testing phase. Unfortunately i am experiencing difficulties, that i think could derive from wine. First of all my setup vst:/opt/fst # uname -a; wine --version Linux vst 2.6.15 #21 PREEMPT Thu Mar 30 22:11:02 CEST 2006 i686 unknown Wine 20050725 Also i am using FreeST which is a binary in order to mount and maintain the vst plugins. The server runs as a x client and my development laptop as x server. This setup works satisfactory i can display any graphical windows on my laptop including wine loaded windows executables. now though, when loading certain plugins on the server (x client) (these all work fine on my local development host) i get a weird x server fault 8<----8<----8<----8<----8<----8<----8<---- vst:/opt/fst # ./fst /mnt/testsuite/oberon4/Oberon-8.dll yo... lets see... The program 'fst.exe.so' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAccess (attempt to access private resource denied)'. (Details: serial 114 error_code 10 request_code 144 minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) 8<----8<----8<----8<----8<----8<----8<---- An xdpyinfo on my xserver gives me ben(a)barney:~> xdpyinfo -queryExt | grep 144 MIT-SHM (opcode: 144, base event: 94, base error: 166) So the MIT-SHM extension seems to be the source of the trouble. looking into the MIT-SHM extension headers gives me the minor opcode: ben(a)barney:/usr/include/X11/extensions> less XShm.h ... #define X_ShmQueryVersion 0 #define X_ShmAttach 1 #define X_ShmDetach 2 #define X_ShmPutImage 3 #define X_ShmGetImage 4 #define X_ShmCreatePixmap 5 ... so attaching a shared memory pixmap appears to be causing the trouble. Now I`m not sure yet if a wine or fst function is causing the trouble. It could derive from some Gtk call... Isn't it problematic to use the shared memory extension when working on a remote display? Now some google entries tell me one must have been able to disable wine using xshm in /etc/wine.conf for example. Is this still so because i can not find any config file allowing this in my distro. And using winecfg didn't really deliver results either. My handicap is my lack of profound knowledge in wine and x matters. Maybe you guys now some work around or can imagine what could be causing all the havoc here... Any help would be great... thank for your time, Cheers, bf -- ------------------- Benjamin Fabricius German Student Lawo AG
"Benjamin Fabricius" <benjamin.fabricius(a)lawo.de> wrote:
I am working on a vst (audio-plugin-)server with embedded linux.
Everything is up and running in a testing phase. Unfortunately i am experiencing difficulties, that i think could derive from wine.
First of all my setup
vst:/opt/fst # uname -a; wine --version Linux vst 2.6.15 #21 PREEMPT Thu Mar 30 22:11:02 CEST 2006 i686 unknown Wine 20050725
[skipped]
so attaching a shared memory pixmap appears to be causing the trouble.
Now I`m not sure yet if a wine or fst function is causing the trouble. It could derive from some Gtk call...
Isn't it problematic to use the shared memory extension when working on a remote display?
Please try more current Wine version, very likely the problem was already fixed. -- Dmitry.
Benjamin Fabricius <benjamin.fabricius(a)lawo.de> writes:
vst:/opt/fst # ./fst /mnt/testsuite/oberon4/Oberon-8.dll yo... lets see... The program 'fst.exe.so' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAccess (attempt to access private resource denied)'. (Details: serial 114 error_code 10 request_code 144 minor_code 1) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
Wine will handle that error properly, but here it sounds like fst (or more likely Gtk) has replaced the Wine error handler with its own, so Wine doesn't get a chance to handle it. -- Alexandre Julliard julliard(a)winehq.org
On Tue, 13 Jun 2006 16:22:17 +0200, Alexandre Julliard wrote:
Wine will handle that error properly, but here it sounds like fst (or more likely Gtk) has replaced the Wine error handler with its own, so Wine doesn't get a chance to handle it.
Yes, that's the GTK+ error handler. Benjamin, this is a bug in FreeST and you should report it to the developers there. Fixing this is not very difficult, hopefully it can be resolved soon. thanks -mike
Am Mittwoch, den 14.06.2006, 13:40 +0100 schrieb Mike Hearn:
On Tue, 13 Jun 2006 16:22:17 +0200, Alexandre Julliard wrote:
Wine will handle that error properly, but here it sounds like fst (or more likely Gtk) has replaced the Wine error handler with its own, so Wine doesn't get a chance to handle it.
Yes, that's the GTK+ error handler. Benjamin, this is a bug in FreeST and you should report it to the developers there. Fixing this is not very difficult, hopefully it can be resolved soon.
Hey, Thanks for the help! I added an empty error handler and it seems as if wine is now taking care of turning xshm off... just as it is supposed to! This would have taken me ages without your hint.. thanks! A big thank you also to Alexandre Julliard who gave the me the same advice. Have a great day.. Cheers, ..Ben
thanks -mike
-- ------------------- Benjamin Fabricius German Student Lawo AG
participants (4)
-
Alexandre Julliard -
Benjamin Fabricius -
Dmitry Timoshkov -
Mike Hearn