wine XShm problem on remote display

[Benjamin Fabricius]

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@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@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

[Dmitry Timoshkov]

"Benjamin Fabricius"  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.

[Alexandre Julliard]

Benjamin Fabricius  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.

[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.

thanks -mike

[Benjamin Fabricius]

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