-
KenSharp
- Level 4
- Posts: 103
- Joined: Mon Jul 13, 2009 8:52 pm
wine client error:0: version mismatch 432/431
Can someone tell me why, despite using a completely clean tree, I keep getting this on a Wine64 build?
Code: Select all
wine client error:0: version mismatch 432/431.
Your wine binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?It’s getting on my bloody nerves!
TIA
-
DanKegel
- Moderator
- Posts: 1164
- Joined: Wed May 14, 2008 11:44 am
Post
by DanKegel » Wed Jun 13, 2012 11:22 am
Yes, this means you’re trying to run two different
versions of wine at the same time somehow,
and clients from one version are trying to connect to
the server from another.
This can happen if you start a wine app, upgrade to a new version
of wine, and then try to run wine apps while that app is still running with the old wineserver. (Quitting the app and waiting ten seconds, or rebooting, would take care of that.)
-
KenSharp
- Level 4
- Posts: 103
- Joined: Mon Jul 13, 2009 8:52 pm
Post
by KenSharp » Wed Jun 13, 2012 11:32 am
That’s what I thought. Sadly I’m not running any version of Wine. sigh
-
KenSharp
- Level 4
- Posts: 103
- Joined: Mon Jul 13, 2009 8:52 pm
Post
by KenSharp » Wed Jun 13, 2012 11:39 am
Code: Select all
$ wineclean ; ./wine64 winecfg
wine: created the configuration directory '/home/test/.wine'
wine client error:0: version mismatch 432/431.
Your wine binary was not upgraded correctly,
or you have an older one somewhere in your PATH.
Or maybe the wrong wineserver is still running?
wine: configuration in '/home/test/.wine' has been updated.where
Code: Select all
$ cat ~/bin/wineclean
#!/bin/sh
wineserver -k ;
pkill -u test wine- ;
pkill -u test .exe ;
pkill -u test Apple ; # Apple iTunes
rm --one-file-system $(xdg-user-dir DESKTOP)/*.desktop 2> /dev/null
rm --one-file-system $(xdg-user-dir DESKTOP)/*.lnk 2> /dev/null
rm ~/.local/share/mime/interface/x-winamp* 2> /dev/null
rm ~/.local/share/applications/wine-*.desktop 2> /dev/null
rm -rf ~/.local/share/applications/wine/* 2> /dev/null
rm ~/.local/share/desktop-directories/* 2> /dev/null
rm ~/.local/share/applications/mimeinfo.cache 2> /dev/null # AFAICT only used by Wine
rm ~/.config/menus/applications-merged/wine*.menu 2> /dev/null
rm -rf ~/.local/share/wineprefixes 2> /dev/null # Winetricks
rm -rf ~/My Library 2> /dev/null # MS Reader
rm -rf ~/TomTom 2> /dev/null # TomTom HOME
rm -rf ~/Dreamboat 2> /dev/null # Skeedreceiver
rm -rf ~/MaxIm DL 5 2> /dev/null #MaxIm DL 5
rm -rf ~/.wine
# If "all" is added then all wineprefixes in ~ should be cleaned
if [ "$1" = "all" ]
then
echo "Cleaning ALL wineprefixes"
rm -rf ~/.wine.*
echo "Done."
echo
fi
# Set up a WINEPREFIX in /tmp (handy)
rm -rf /tmp/wine 2> /dev/null
mkdir /tmp/wineand without cleaning ~/.wine
Code: Select all
$ err:seh:call_stack_handlers invalid frame 2410f0 (0x142000-0x240000)
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.
wine client error:13: write: Bad file descriptor
err:seh:call_stack_handlers invalid frame 2410f0 (0x142000-0x240000)
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.
wine client error:13: write: Bad file descriptor
err:seh:call_stack_handlers invalid frame 2410f0 (0x142000-0x240000)
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.
wine client error:1b: write: Bad file descriptor
err:seh:call_stack_handlers invalid frame 2410f0 (0x142000-0x240000)
err:seh:raise_exception Exception frame is not in stack limits => unable to dispatch exception.
wine client error:1b: write: Bad file descriptorThere are no compile errors so… shrug
I’m having this issue with lutris v0.4.18, installed using Arch AUR package on Manjaro linux (Arch variant).
My system wine installed is wine-staging-3.8. If I use anything newer than that I end up with client version mismatch.
For example, using the Blizzard Battle.net app installer from Lutris’s web page, the installer installs wine version pba-firerat-3.9-x86_64. When it attempts to start the installation it fails with:
DEBUG 2018-06-05 13:52:17,381 [thread]:Running command: "/home/username/.local/share/lutris/runners/wine/pba-firerat-3.9-x86_64/bin/wine" "/home/username/.cache/lutris/installer/battlenet/Battle.net-Setup.exe"
DEBUG 2018-06-05 13:52:17,381 [thread]:Storing environment variable WINEARCH to win64
DEBUG 2018-06-05 13:52:17,382 [thread]:Storing environment variable WINE to /home/username/.local/share/lutris/runners/wine/pba-firerat-3.9-x86_64/bin/wine
DEBUG 2018-06-05 13:52:17,382 [thread]:Storing environment variable WINEPREFIX to /data/lutris/battlenet
DEBUG 2018-06-05 13:52:17,382 [thread]:Storing environment variable LD_LIBRARY_PATH to /usr/lib:/usr/lib32:/home/username/.local/share/lutris/runtime/lib32:/home/username/.local/share/lutris/runtime/steam/i386/lib/i386-linux-gnu:/home/username/.local/share/lutris/runtime/steam/i386/lib:/home/username/.local/share/lutris/runtime/steam/i386/usr/lib/i386-linux-gnu:/home/username/.local/share/lutris/runtime/steam/i386/usr/lib:/home/username/.local/share/lutris/runtime/lib64:/home/username/.local/share/lutris/runtime/steam/amd64/lib/x86_64-linux-gnu:/home/username/.local/share/lutris/runtime/steam/amd64/lib:/home/username/.local/share/lutris/runtime/steam/amd64/usr/lib/x86_64-linux-gnu:/home/username/.local/share/lutris/runtime/steam/amd64/usr/lib
wine client error:0: version mismatch 554/549.
The wine command above is attempting to pull libwine from the system’s installed wine, as demonstrated below:
~]$ LD_LIBRARY_PATH="/usr/lib:/usr/lib32:/home/username/.local/share/lutris/runtime/lib32:/home/username/.local/share/lutris/runtime/steam/i386/lib/i386-linux-gnu:/home/username/.local/share/lutris/runtime/steam/i386/lib:/home/username/.local/share/lutris/runtime/steam/i386/usr/lib/i386-linux-gnu:/home/username/.local/share/lutris/runtime/steam/i386/usr/lib:/home/username/.local/share/lutris/runtime/lib64:/home/username/.local/share/lutris/runtime/steam/amd64/lib/x86_64-linux-gnu:/home/username/.local/share/lutris/runtime/steam/amd64/lib:/home/username/.local/share/lutris/runtime/steam/amd64/usr/lib/x86_64-linux-gnu:/home/username/.local/share/lutris/runtime/steam/amd64/usr/lib" ldd -r /home/username/.local/share/lutris/runners/wine/pba-firerat-3.9-x86_64/bin/wine
linux-gate.so.1 (0xf7f28000)
libwine.so.1 => /usr/lib32/libwine.so.1 (0xf7d58000)
libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf7d39000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf7b5e000)
libdl.so.2 => /usr/lib32/libdl.so.2 (0xf7b59000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f2a000)
If I remove the prepended «/usr/lib» and «/usr/lib32» it then pulls the correct libwine as demonstrated below:
~]$ LD_LIBRARY_PATH="/home/username/.local/share/lutris/runtime/lib32:/home/username/.local/share/lutris/runtime/steam/i386/lib/i386-linux-gnu:/home/username/.local/share/lutris/runtime/steam/i386/lib:/home/username/.local/share/lutris/runtime/steam/i386/usr/lib/i386-linux-gnu:/home/username/.local/share/lutris/runtime/steam/i386/usr/lib:/home/username/.local/share/lutris/runtime/lib64:/home/username/.local/share/lutris/runtime/steam/amd64/lib/x86_64-linux-gnu:/home/username/.local/share/lutris/runtime/steam/amd64/lib:/home/username/.local/share/lutris/runtime/steam/amd64/usr/lib/x86_64-linux-gnu:/home/username/.local/share/lutris/runtime/steam/amd64/usr/lib" ldd -r /home/username/.local/share/lutris/runners/wine/pba-firerat-3.9-x86_64/bin/wine
linux-gate.so.1 (0xf7f32000)
libwine.so.1 => /home/username/.local/share/lutris/runners/wine/pba-firerat-3.9-x86_64/bin/../lib/libwine.so.1 (0xf7d61000)
libpthread.so.0 => /usr/lib32/libpthread.so.0 (0xf7d08000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf7b2d000)
libdl.so.2 => /usr/lib32/libdl.so.2 (0xf7b28000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f34000)
I had a look at the runtime.py that is mentioned in a similar issue (#875) and it appears that /usr/lib and /usr/lib32 are manually prepended to the library path, as seen below:
149 # Put /usr/lib at the beginning, this prioritizes system libraries over
150 # the Lutris and Steam runtimes.
151 paths = ["/usr/lib"]
152 if os.path.exists("/usr/lib32"):
153 # Also let the system take over 32bit libs.
154 paths.append("/usr/lib32")
155
156 # Then resolve absolute paths for the runtime
157 paths += [os.path.join(RUNTIME_DIR, path) for path in runtime_paths]
158
159 if os.environ.get('LD_LIBRARY_PATH'):
160 paths.append(os.environ['LD_LIBRARY_PATH'])
I manually updated runtime.py to append these paths to the library path as below:
149 # Put /usr/lib at the beginning, this prioritizes system libraries over
150 # the Lutris and Steam runtimes.
151 sys_paths = ["/usr/lib"]
152 if os.path.exists("/usr/lib32"):
153 # Also let the system take over 32bit libs.
154 sys_paths.append("/usr/lib32")
155
156 # Then resolve absolute paths for the runtime
157 paths += [os.path.join(RUNTIME_DIR, path) for path in runtime_paths]
158 paths += [p for p in sys_paths]
159
160 if os.environ.get('LD_LIBRARY_PATH'):
161 paths.append(os.environ['LD_LIBRARY_PATH'])
This, however, does not fix the issue, it still pulls the libwine library from /usr/lib32.
If I do not append the /usr/lib|/usr/lib32 paths at all, then the installer works, and I do not get the version mismatch, as below:
149 # Put /usr/lib at the beginning, this prioritizes system libraries over
150 # the Lutris and Steam runtimes.
151 sys_paths = ["/usr/lib"]
152 if os.path.exists("/usr/lib32"):
153 # Also let the system take over 32bit libs.
154 sys_paths.append("/usr/lib32")
155
156 # Then resolve absolute paths for the runtime
157 paths += [os.path.join(RUNTIME_DIR, path) for path in runtime_paths]
158 # paths += [p for p in sys_paths]
159
160 if os.environ.get('LD_LIBRARY_PATH'):
161 paths.append(os.environ['LD_LIBRARY_PATH'])
I guess this works as it cannot find it in the global library path and defaults to looking in the «current directory» that the application is being called from.
I wonder, is it possible, from lutris, to find out what lutris wine version is being used and then, manually prepending the lutris wine path to the ld_library_path?
-
wine client error: version mismatch
I’ve seen a few solutions to this on google but my situation seems a little unique.
I have used this exact technique on my desktop comp, running ubuntu 10.04
Now i’m trying this on my laptop that runs puppy linux 5.0.
Pretty much what is happening is, you need some strange dll tweaks and registry tweaks to run this game properly, so these guys (http://lookias.inventforum.com/viewtopic.php?p=19#19) made a modified wine that has the tweaks, and is available for download.
On my desktop i just downloaded their modified wine, went to the path that the wine binaries are in and typed
Code:
./wine /root/.wine/drive_c/..../WA.exe /nointro
and it works perfectly.
now i’m trying to do the same on my laptop, but i’m not getting this error:
«Wine client error:0: version mismatch 0/398
your wineserver binary was not upgraded properly
or you have an older one somewhere in your path
Or maybe the wrong winserver is still running?»It’s true that i have a different version of wine installed on this computer, but i don’t think that should matter. if i type winserver into console (which runs the wineserver already installed on the computer, i’m able to use the ./wine command to run the game but it gets the same bug that happens when i run using the unmodified wine. then if i run wineserver -kill and try to run their wine server using ./wineserver, i get the version mismatch error. I’m thinking about uninstalling the wine already on this computer and trying again then. But i’m not sure if that’s necessary.
-
Re: wine client error: version mismatch
This means a different version of Wine is already running when you get that message.
Also, you should be running programs this way:
http://wiki.winehq.org/FAQ#head-8d8c…b61e5c730566e0
-
Re: wine client error: version mismatch
ah yes i got that much figured out, so how do I ‘turn off’ that other version of wine?
-
Re: wine client error: version mismatch
i’m having trouble fully uninstalling wine… the package remover on my os doesnt seem to remove it fully, as i can still use the wine command in terminal after ‘uninstalling’ it
-
Re: wine client error: version mismatch
Originally Posted by Metrop021
i’m having trouble fully uninstalling wine… the package remover on my os doesnt seem to remove it fully, as i can still use the wine command in terminal after ‘uninstalling’ it
This likely means you tried to install wine in more than one way. IE source, packages, alternate methods.
Also this was probably done without fully removing the previous installation.
If you installed wine from source you’ll need to run a make uninstall from the source directory before installing deb packages.
Originally Posted by Metrop021
wine client error:0: version mismatch 400/410.
| Author | Replies |
| grendelson | Tuesday 14 December 2010 at 6:34 |
grendelson |
When I try to run either BioShock or Bloodbowl ( which used to run ) I get the following:
/usr/share/playonlinux/playonlinux —run «Bioshock»
wine client error:0: version mismatch 400/410. If I start the app with: It immediately gives an error in the application — this happens now with bloodbowl as well — both are digital downloads ( d2d for bioshock) Not sure what to try — I’ve tried changing the wine version in POL. Prnice of Persia Warrirowithin still runs fine via the env=WINEPREFIX command line start (wine vers 1.1.4) Ubuntu 10.10 , AMD 64, 2GB mem 512 Mb Nvidai… Thanks |
| grendelson | Tuesday 14 December 2010 at 7:04 |
| grendelson |
the wine version given from /usr/bin/wine is 1.2.1 but the wine version shown in POL System is 1.3.5 so I set the games to use 1.3.5 — now I don’t get the mismatch error but I can’t star the games still — The Applications that work are Prince of Persia and Steam — they are using 1.1.4 wine. |
| GNU_Raziel | Tuesday 14 December 2010 at 11:30 |
GNU_Raziel |
Use «Close All» button in POL befaire launching your game. This will unsure that ALL wine related process are killed. Why you should use OpenGL and not DirectX |
| grendelson | Tuesday 14 December 2010 at 21:01 |
| grendelson |
Thanks for the reply! I did this but the above games still won’t start.
There seems to be 2 issues here — using the wrong version of wine and then the fact I am on Ubuntu 10.10 ( upgrade form 10.04) there seems to be other posts that state that Ubuntu 10.10 Just broke POL and there was no attempt to support it — is this also true? |
| grendelson | Tuesday 14 December 2010 at 21:14 |
| grendelson |
Set all the non-working games (bloodbowl, bioshock, IE7) to System for wine version and ran from playonlinux —run «game» Here is sample output form cmd line:
playonlinux —run «Bioshock»
wine: Unhandled page fault on read access to 0x00000000 at address 0x10a4f9d3 (thread 0009), starting debugger… |
| grendelson | Thursday 16 December 2010 at 6:30 |
| grendelson |
I was about to format and reinstall Ubuntu 10.04 when I thought of creating a NEW User Account. I then changed the ownership to my user account and swapped /home/<user> names. This gave my user account a brand new Home Dir with Nothing more then the generic new user Home dir. I moved the .Playonlinux folder from the old home to the new home and reran the 1.1 upgrade — it ran flawlessly and Bioshock started with the additional Exe! SO now all I need to figure out is how to get Bloodbowl to run again and I can stay on Ubuntu 10.10 — I may still reinstall- but I’ve been wanting to :start over: on my home dir for some time Any hints on Bloodbowl? Anyone else running it under 10.10? |
