Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
FIXED: After profile switch 13.0-17.0 Wine apps stop working
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
blopsalot
Apprentice
Apprentice


Joined: 28 Jan 2017
Posts: 231

PostPosted: Sat Mar 31, 2018 3:30 pm    Post subject: Reply with quote

Chiitoo wrote:
Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.

On another note, Portal 2 seems to work with '-mstackrealign' using glibc-2.25-r10 and gcc-6.4.0-r1 as well.

I'm not sure where the bug really is, but I'm thinking Portal 2 (and other applications affected), or gcc/glibc.


Here's a pretty good technical description, seems like it would be an issue effecting many others if it was not handled already though.
https://bugs.archlinux.org/task/27560

Erdie did you ever try using a 32bit prefix? I don't game anymore, but copy protection and 64bit prefix was always a problem.
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2569
Location: Here and Away Again

PostPosted: Sat Mar 31, 2018 4:36 pm    Post subject: Reply with quote

If that would be the same issue, I believe a lot more would be affected indeed.

Can't say it isn't the same issue, but I don't even remember hitting it back when it was reported there (could have forgotten all about it of course).

Either way, thanks for mentioning it!
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Sat Mar 31, 2018 9:00 pm    Post subject: Reply with quote

Chiitoo wrote:
Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.



I thought I have to use it like this:

Code:

CPU_FLAGS_X86="<Output of cpuid2cpuflags>"


and put this into make.conf. In the last 24 hours I recompiled about 1300 packages with this option. If you say this are USE flags I have to rebuild my system again :(
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2569
Location: Here and Away Again

PostPosted: Sun Apr 01, 2018 10:48 am    Post subject: Reply with quote

No, that seems correct.

I meant that they were regular USE-flags in the past, which got moved into their own variable.

There's an article over at our wiki, CPU_FLAGS_X86, that will explain it more fully. :]

As I mentioned though, as far as I know, these shouldn't affect packages other than those that actually make use of them.

For example, using 'app-portage/eix' on 'media-sound/audacity':

Code:
[I] media-sound/audacity
     Available versions:  2.1.3-r1^t{tbz2} (~)2.2.1^t{tbz2} (~)2.2.2^t{tbz2} {alsa doc ffmpeg +flac id3tag jack +ladspa +lame libav +lv2 mad +midi nls +portmixer sbsms +soundtouch twolame vamp +vorbis +vst CPU_FLAGS_X86="sse"}

You'll notice the CPU_FLAGS_X86 there.

CFLAGS however would affect most packages (for some, such as 'sys-libs/glibc' they are stripped to avoid a lot of issues users would easily encounter).

Going back to the Wine-specific issues, if they indeed stem from the same root cause, I wonder if building Wine itself with '-mstackrealign' would be enough. It might not have anything to do with it, but I would try it out if I had an example program that's crashing. Our Wine builds also strip CFLAGS, but there's USE="custom-cflags" for cases where that's not desirable.

I might not put too much hope on it though, and it might be a waste of CPU cycles, but I would still try it out just out of curiosity.

Also, yeah, as mentioned, trying out a 32-bit prefix is always a good idea when something goes wrong while using Wine. It's a relatively 'cheap' test, and amongst the top few 'first things to try' along with 'clean prefix' for example. :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Sun Apr 01, 2018 7:54 pm    Post subject: Reply with quote

I did now:

Code:

WINEARCH="win32" WINEPREFIX="~/wine32" wineboot


I assume if I just relauch a wine application it will now uwe this prefix? So I did and the afprod.exe (Aerofly professional deluse) crashed in the sam way as I posted initially.

By the way, I have to out me as a n00b ;) How can I build wine with a non-standard CPU flag? I this done with a package.use entry? I which way do I have to maintain it?
Just in this way:
Code:

echo "app-emulation/wine-staging CPU_FLAGS_X86=<my different option>  >> /etc/portage/package.use


?
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2569
Location: Here and Away Again

PostPosted: Sun Apr 01, 2018 9:03 pm    Post subject: Reply with quote

Erdie wrote:
I did now:

Code:

WINEARCH="win32" WINEPREFIX="~/wine32" wineboot


I assume if I just relauch a wine application it will now uwe this prefix? So I did and the afprod.exe (Aerofly professional deluse) crashed in the same way as I posted initially.

You'll need to either do something like this:

Code:
$ WINEPREFIX="~/wine32" wine afprod.exe

Or, for example, something like this:

Code:
$ export WINEPREFIX="~/wine32"

With this, you can run Wine in the current shell session as if the default prefix was '~/wine32' (for 'session' think of the virtual terminal window/tab). The default is always "$HOME/.wine" unless you permanently, or temporarily change it in some way not limited to these two examples.

You can think of the new prefix as a new Windows installation, meaning you'll need to re-install (or move, if that's enough for the application) the software into it before you can use it, just like the first time you ever used it.

You do not need to specifiy WINEARCH every time, as it can not be changed after the prefix has been created.

I prefer keeping the default as it is, and specify the WINEPREFIX for all custom prefix needs, when I need them (if I keep one around for longer, I create a small 'wrapper' script for it).

Quote:
By the way, I have to out me as a n00b ;) How can I build wine with a non-standard CPU flag? I this done with a package.use entry? I which way do I have to maintain it?
Just in this way:
Code:

echo "app-emulation/wine-staging CPU_FLAGS_X86=<my different option>  >> /etc/portage/package.use


?

And I'm the noob unlimited. :]

It's almost always better to ask if unsure about something, though I'm horrible at that myself, and instead tend to go down the trial and error path.

There probably shouldn't be a need to think about the CPU_FLAGS_X86 after you've set them in 'make.conf'. If you wanted to try the 'custom-cflags' I mentioned, the most easy/quick way I can think of right now would be something like this:

Code:
# CFLAGS="$CFLAGS -mstackrealign" CXXFLAGS="$CFLAGS" USE="custom-cflags" emerge -1a wine-vanilla

This will not modify your existing configuration, but adds to them only for this one emerge, and you don't need to edit any files and forget to change them back after the test. :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Mon Apr 02, 2018 7:32 am    Post subject: Reply with quote

blopsalot wrote:
Chiitoo wrote:
Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.

On another note, Portal 2 seems to work with '-mstackrealign' using glibc-2.25-r10 and gcc-6.4.0-r1 as well.

I'm not sure where the bug really is, but I'm thinking Portal 2 (and other applications affected), or gcc/glibc.


Here's a pretty good technical description, seems like it would be an issue effecting many others if it was not handled already though.
https://bugs.archlinux.org/task/27560

Erdie did you ever try using a 32bit prefix? I don't game anymore, but copy protection and 64bit prefix was always a problem.


Hi Blopsalot,

I tested 32bit prefix without sucess, but let me ask you, is this what you explained about portal 2 and -mstackrealign related to wine ? It seems to be. My portal2 is running native or do you think the portal version is a wine - based thing?

-Erdie
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Mon Apr 02, 2018 7:36 am    Post subject: Reply with quote

I build wine-staging with "-mstackrealign" and startet afproc.exe with 32bit prefix. The result is:

Code:

WINEPREFIX="/home/martin/.wine32" wine ~/.wine32/drive_c/Program\ Files\ \(x86\)/afpd/afprod.exe
fixme:winediag:start_process Wine Staging 2.21 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
fixme:dwmapi:DwmIsCompositionEnabled 0x6d5d3018
fixme:iphlpapi:NotifyIpInterfaceChange (family 0, callback 0x6a0cb608, context 0x83b750, init_notify 0, handle 0x103e794): stub
wine: configuration in '/home/martin/.wine32' has been updated.
wine: Unhandled page fault on read access to 0x00000008 at address 0x43eff8 (thread 0009), starting debugger...


-Erdie
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2569
Location: Here and Away Again

PostPosted: Mon Apr 02, 2018 8:02 pm    Post subject: Reply with quote

Erdie wrote:
blopsalot wrote:
Chiitoo wrote:
Yeah, those flags used to be regular USE-flags, but now they have this dedicated variable.

On another note, Portal 2 seems to work with '-mstackrealign' using glibc-2.25-r10 and gcc-6.4.0-r1 as well.

I'm not sure where the bug really is, but I'm thinking Portal 2 (and other applications affected), or gcc/glibc.


Here's a pretty good technical description, seems like it would be an issue effecting many others if it was not handled already though.
https://bugs.archlinux.org/task/27560

Erdie did you ever try using a 32bit prefix? I don't game anymore, but copy protection and 64bit prefix was always a problem.


Hi Blopsalot,

I tested 32bit prefix without sucess, but let me ask you, is this what you explained about portal 2 and -mstackrealign related to wine ? It seems to be. My portal2 is running native or do you think the portal version is a wine - based thing?

-Erdie

I guess you meant me with the part with portals. :]

When I was talking about Portal 2, it was the Linux build I was testing (well I did also test running the Windows build via Wine, but it worked either way).

One of the things I've been wondering is indeed if the cause is the same for the native Linux game issues, and your Wine issues. It still might be, but I'm not sure what to try next to verify it.

Erdie wrote:
I build wine-staging with "-mstackrealign" and startet afproc.exe with 32bit prefix. The result is:

Code:

WINEPREFIX="/home/martin/.wine32" wine ~/.wine32/drive_c/Program\ Files\ \(x86\)/afpd/afprod.exe
fixme:winediag:start_process Wine Staging 2.21 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
fixme:dwmapi:DwmIsCompositionEnabled 0x6d5d3018
fixme:iphlpapi:NotifyIpInterfaceChange (family 0, callback 0x6a0cb608, context 0x83b750, init_notify 0, handle 0x103e794): stub
wine: configuration in '/home/martin/.wine32' has been updated.
wine: Unhandled page fault on read access to 0x00000008 at address 0x43eff8 (thread 0009), starting debugger...


-Erdie

Hm. It does seem a bit different from before at least.

Does it just hang there, without producing the backtrace?

Just for safety, I would try

Code:
$ cd ~/.wine32/drive_c/Program\ Files\ \(x86\)/afpd/

first, then

Code:
$ WINEPREFIX="/home/martin/.wine32" wine afprod.exe

because some Windows applications don't like it if the working directory is something else than where the executable is. In Windows it is set differently, so the applications sometimes panic when it's not what they expect. Maybe this one works just fine like this, and you know it does, but I figured it's worth mentioning. :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Sun Apr 15, 2018 8:01 am    Post subject: Reply with quote

Sorry for my late response. I am sometimes very busy outside of the gentoo world.

this is the results of running afprod.exe with wine32:

Code:

Unhandled exception: page fault on read access to 0xffffffff in 32-bit code (0xf73c01fa).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
 EIP:f73c01fa ESP:0032f108 EBP:7cdc85a0 EFLAGS:00010246(  R- --  I  Z- -P- )
 EAX:00000000 EBX:00000000 ECX:f7512960 EDX:00000000
 ESI:00000002 EDI:00000003
Stack dump:
0x0032f108:  7ce742c8 00000001 00000001 f7514000
0x0032f118:  00000000 00000000 f75147b0 dc15e000
0x0032f128:  0032f3f8 00000001 f73c728b 00000000
0x0032f138:  f7514000 00000004 00000000 f73c8680
0x0032f148:  7ce68dd8 00000000 f73c728b 0032f3f8
0x0032f158:  00000068 00000000 0032f448 795774f3
000c: sel=0067 base=00000000 limit=00000000 32-bit r-x
Backtrace:
=>0 0xf73c01fa _IO_file_seekoff+0x52() in libc.so.6 (0x7cdc85a0)
  1 0xf73bc821 fseek+0x80() in libc.so.6 (0x0032f240)
  2 0x79c974ca in libnvidia-glcore.so.390.42 (+0x13af4c9) (0x00000215)
  3 0x79c9af3e in libnvidia-glcore.so.390.42 (+0x13b2f3d) (0x0032f330)
  4 0x79c9604b in libnvidia-glcore.so.390.42 (+0x13ae04a) (0x0032f330)
  5 0x79c87c0f in libnvidia-glcore.so.390.42 (+0x139fc0e) (0x7cea8ec0)
  6 0x79c87dc8 in libnvidia-glcore.so.390.42 (+0x139fdc7) (0x00000000)
  7 0x79c89d8c in libnvidia-glcore.so.390.42 (+0x13a1d8b) (0x0032f8dc)
  8 0x79e8308f in libnvidia-glcore.so.390.42 (+0x159b08e) (0x7d24b008)
  9 0x79e85fa4 in libnvidia-glcore.so.390.42 (+0x159dfa3) (0x7d6d5008)
  10 0x79ccd8fe in libnvidia-glcore.so.390.42 (+0x13e58fd) (0x7cd7601c)
  11 0x79ccdbfe in libnvidia-glcore.so.390.42 (+0x13e5bfd) (0x7cd7601c)
  12 0x79e83afe in libnvidia-glcore.so.390.42 (+0x159bafd) (0x7d434000)
  13 0x79e81f0b in libnvidia-glcore.so.390.42 (+0x1599f0a) (0x7d434000)
  14 0x79e82b88 in libnvidia-glcore.so.390.42 (+0x159ab87) (0x7d434000)
  15 0x79ec11f6 in libnvidia-glcore.so.390.42 (+0x15d91f5) (0x7d434000)
  16 0x7d831c20 (0x0032fc38)
  17 0x00542534 in afprod (+0x142533) (0x08c9b9e4)
0xf73c01fa _IO_file_seekoff+0x52 in libc.so.6: ldsl   %eax,%edi
Modules:
Module   Address         Debug info   Name (85 modules)
PE     400000- 9866000   Export          afprod
ELF   788e8000-7a7f9000   Dwarf           libnvidia-glcore.so.390.42
ELF   7a800000-7a938000   Deferred        opengl32<elf>
  \-PE   7a820000-7a938000   \               opengl32
ELF   7b400000-7b7ef000   Deferred        kernel32<elf>
  \-PE   7b420000-7b7ef000   \               kernel32
ELF   7bc00000-7bd2f000   Deferred        ntdll<elf>
  \-PE   7bc40000-7bd2f000   \               ntdll
ELF   7c000000-7c004000   Deferred        <wine-loader>
ELF   7d5b0000-7d6c9000   Deferred        libglx_nvidia.so.0
ELF   7d720000-7d7a0000   Deferred        libgldispatch.so.0
ELF   7d7a0000-7d822000   Deferred        libgl.so.1
ELF   7d878000-7d960000   Deferred        libasound.so.2
ELF   7d980000-7d99f000   Deferred        libglx.so.0
ELF   7d9b0000-7d9e1000   Deferred        winealsa<elf>
  \-PE   7d9c0000-7d9e1000   \               winealsa
ELF   7da10000-7db42000   Deferred        oleaut32<elf>
  \-PE   7da30000-7db42000   \               oleaut32
ELF   7dd10000-7dd48000   Deferred        uxtheme<elf>
  \-PE   7dd20000-7dd48000   \               uxtheme
ELF   7dd48000-7de66000   Deferred        comctl32<elf>
  \-PE   7dd50000-7de66000   \               comctl32
ELF   7dfb8000-7dfdb000   Deferred        mmdevapi<elf>
  \-PE   7dfc0000-7dfdb000   \               mmdevapi
ELF   7dfe0000-7e02c000   Deferred        dinput<elf>
  \-PE   7dff0000-7e02c000   \               dinput
ELF   7e058000-7e05f000   Deferred        libxfixes.so.3
ELF   7e060000-7e06c000   Deferred        libxcursor.so.1
ELF   7e078000-7e07d000   Deferred        libnvidia-tls.so.390.42
ELF   7e108000-7e132000   Deferred        libexpat.so.1
ELF   7e138000-7e182000   Deferred        libfontconfig.so.1
ELF   7e188000-7e1c5000   Deferred        libpng16.so.16
ELF   7e1c8000-7e1da000   Deferred        libbz2.so.1
ELF   7e1e0000-7e1f9000   Deferred        libz.so.1
ELF   7e200000-7e2bb000   Deferred        libfreetype.so.6
ELF   7e310000-7e319000   Deferred        librt.so.1
ELF   7e320000-7e33c000   Deferred        libbsd.so.0
ELF   7e340000-7e36c000   Deferred        libxcb.so.1
ELF   7e370000-7e4bc000   Deferred        libx11.so.6
ELF   7e4c8000-7e4db000   Deferred        libxi.so.6
ELF   7e4e0000-7e4e4000   Deferred        libxcomposite.so.1
ELF   7e4e8000-7e4f5000   Deferred        libxrandr.so.2
ELF   7e4f8000-7e504000   Deferred        libxrender.so.1
ELF   7e508000-7e50f000   Deferred        libxxf86vm.so.1
ELF   7e510000-7e59d000   Deferred        winex11<elf>
  \-PE   7e520000-7e59d000   \               winex11
ELF   7e5a0000-7e5fa000   Deferred        libncurses.so.6
ELF   7e600000-7e607000   Deferred        libxdmcp.so.6
ELF   7e608000-7e60d000   Deferred        libxau.so.6
ELF   7e610000-7e626000   Deferred        libxext.so.6
ELF   7e628000-7e64c000   Deferred        imm32<elf>
  \-PE   7e630000-7e64c000   \               imm32
ELF   7e650000-7e6c1000   Deferred        setupapi<elf>
  \-PE   7e660000-7e6c1000   \               setupapi
ELF   7e6c8000-7e6e1000   Deferred        hid<elf>
  \-PE   7e6d0000-7e6e1000   \               hid
ELF   7e6e8000-7e704000   Deferred        dinput8<elf>
  \-PE   7e6f0000-7e704000   \               dinput8
ELF   7e708000-7e78a000   Deferred        rpcrt4<elf>
  \-PE   7e710000-7e78a000   \               rpcrt4
ELF   7e790000-7e8e9000   Deferred        ole32<elf>
  \-PE   7e7b0000-7e8e9000   \               ole32
ELF   7e8f0000-7e93e000   Deferred        dsound<elf>
  \-PE   7e900000-7e93e000   \               dsound
ELF   7e940000-7e95a000   Deferred        version<elf>
  \-PE   7e950000-7e95a000   \               version
ELF   7e960000-7eb61000   Deferred        user32<elf>
  \-PE   7e970000-7eb61000   \               user32
ELF   7eb68000-7eba0000   Deferred        glu32<elf>
  \-PE   7eb70000-7eba0000   \               glu32
ELF   7eba0000-7ec19000   Deferred        advapi32<elf>
  \-PE   7ebb0000-7ec19000   \               advapi32
ELF   7ec20000-7ed49000   Deferred        gdi32<elf>
  \-PE   7ec30000-7ed49000   \               gdi32
ELF   7ef50000-7efac000   Deferred        libm.so.6
ELF   7efb0000-7efbd000   Deferred        libnss_files.so.2
ELF   7efc0000-7efcd000   Deferred        libnss_nis.so.2
ELF   7efd0000-7efeb000   Deferred        libnsl.so.1
ELF   7eff0000-7effa000   Deferred        libnss_compat.so.2
ELF   f7348000-f734d000   Deferred        libdl.so.2
ELF   f7350000-f7518000   Dwarf           libc.so.6
ELF   f7518000-f7537000   Deferred        libpthread.so.0
ELF   f7588000-f7759000   Dwarf           libwine.so.1
ELF   f7760000-f7786000   Deferred        ld-linux.so.2
ELF   f778f000-f7790000   Deferred        [vdso].so
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) Z:\home\martin\.wine\drive_c\Program Files (x86)\afpd\afprod.exe
   ["Z:\home\martin\.wine\drive_c\Program Files (x86)\afpd\afprod.exe"]
   0000004d   15
   0000004c    0
   0000004b    0
   00000009    0 <==
0000000e services.exe
   [C:\windows\system32\services.exe]
   00000022    0
   0000001d    0
   00000013    0
   00000010    0
   0000000f    0
00000011 winedevice.exe
   [C:\windows\system32\winedevice.exe]
   0000001a    0
   00000017    0
   00000016    0
   00000012    0
0000001b plugplay.exe
   [C:\windows\system32\plugplay.exe]
   0000001f    0
   0000001e    0
   0000001c    0
00000020 winedevice.exe
   [C:\windows\system32\winedevice.exe]
   00000027    0
   00000024    0
   00000023    0
   00000021    0
0000002e explorer.exe
   [C:\windows\system32\explorer.exe /desktop]
   00000032    0
   00000031    0
   00000030    0
   0000002f    0
00000050 explorer.exe
   [C:\windows\system32\explorer.exe /desktop]
   00000054    0
   00000053    0
   00000052    0
   00000051    0
System information:
    Wine build: wine-2.21 (Staging)
    Platform: i386
    Version: Windows 7
    Host system: Linux
    Host version: 4.9.76-gentoo-r1


My question is, is it very risky to recompile glibc with "-mstackrealign"? If not, I would like to give it a try because of all other crashes with steam games etc. Clearly spoken, at the moment the whole steam stuff is almost unsuable. I cannot pay money for a new game if the chance that is crashes is about 50:50. This does not hurt me too much, since I am an old guy and the priority of playing games decreased in the last years. But anyway, I liked it for occasional gaming. This does not work anymore.

This is the console output:

Code:

fixme:winediag:start_process Wine Staging 2.21 is a testing version containing experimental patches.
fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
fixme:dwmapi:DwmIsCompositionEnabled 0x6d5d3018
fixme:iphlpapi:NotifyIpInterfaceChange (family 0, callback 0x6a0cb608, context 0x83b750, init_notify 0, handle 0x103e784): stub
wine: configuration in '/home/martin/.wine32' has been updated.
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1600x1200x0 @60! (XRandR 1.2)
wine: Unhandled page fault on read access to 0xffffffff at address 0xf73c01fa (thread 0009), starting debugger...


Have a nice day
Erdie
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2569
Location: Here and Away Again

PostPosted: Sun Apr 15, 2018 10:49 pm    Post subject: Reply with quote

No sorries. :]

I would say that yes, it is fairly risky to mess with the CFLAGS of 'sys-libs/glibc', since it has been made so difficult (easy to by-pass, really, but difficult in the sense of not being possible just by flipping a USE-flag).

I haven't (yet) researched fully what effect the option actually has, but considering Arch Linux packaged glibc like that, at least optionally(?), it should perhaps mean that it's not a huge security issue at least (this is of course assuming a lot).

All that said, I did not notice anything exploding during my tests.

Downgrading glibc is probably something one should be more careful about, though it's doable as well, but can get tricky if several packages was already built against the higher version.

Conclusion being that I can't exactly recommend it if I'm not at least close to 100% sure of the outcome, but like I mentioned, I did try it out myself, and it worked for me.

With decent back-ups, if something did go wrong, it should be easy to go back. At the very least I'd recommend making use of the 'buildpkg' feature (see for example 'man make.conf' and look for 'buildpkg').

See also 'man quickpkg' for backing up already installed files without the need to re-emerge them (if using FEATURES="buildpkg" for example, I believe the package will be over-written in case one with the same version already exists, so one would need to manually move them out of the way before the next build if the old one is supposed to be kept for later).

Feeling a bit scatter-brained, but hopefully I'm making at least some sense...

Now for the console output!

Code:
err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found 1600x1200x0 @60! (XRandR 1.2)

For some reason this makes me want to ask if you have a multi-display set-up? If you do use more than one monitor, it might be a good idea to enable the 'xinerama' USE-flag for Wine (and other packages that have it). It may not fix this particular issue, but I wouldn't be surprised if it helped.

Also, what does the 'xrandr' command display?

According to our wiki article on Xrandr, “graphic drivers like the binary Nvidia or AMD, do not support xrandr”, so the fact it's being tried there seems at least somewhat suspicious.

It might well explain the seemingly bogus colour-depth that's being requested (x0). I can't remember when I've last seen the XRandR message myself (didn't even have 'xrandr' installed though), so I'm not immediately aware of how fatal this can be.

I'd probably try enabling the virtual desktop just to see if that makes any difference, if you didn't try it yet.

Oh and just to make sure, for this run, did you first 'cd' to the 'afpd' directory?

I may have more ideas after a nap. Right now I can't really think of anything else to try. :\
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Mon Apr 16, 2018 8:45 pm    Post subject: Reply with quote

I had a multi monitor setup but recently buyed a new 2k Monitor and now I am using a single monitor setup. In the past, afpd was running fullscreen at 1600x1200. I alredy edited the config files to windowed mode and to check if this is the reason of the segfault but it was not. Normaly the application will automatically fall back to window mode if the selected mode wasnot found. Of course I can do this test again and edit the configuration manually to be sure that is is not the root cause of all mess. Let me go on an do it asap. Now it is almost 11 pm and I will have to work tomorrow so let me postpone this check to tomorrow ;) Have a nice day.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Wed Jun 20, 2018 9:19 am    Post subject: Reply with quote

In the meantime, I had given up - but not completly. Now gcc 7* is out and my hope is that this will change the situation.
I don´t belive that this is a wine issue because the majority of binary application are very unstable after the mentioned profile switch .. even steam games. It does not make sense to play any of them on my system, you can be sure it crashes at some time. And this was DEFINATELY not the case before I switched to gcc-6.4 and the new profle. I played steam games for about 10 years on this system, on (almost) the same hardware. Let´s see what gcc-7* brings to me.
I have to apologize not to react on all questions raised during this discussion, I was tired of endless troubleshooting and the real life has some challanges, too. Anyway I am interesed to get my old apps back to work and a usable gaming enviroment (even if is has lower priority). Thanks to all who tried to help and support.

-Erdie
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2569
Location: Here and Away Again

PostPosted: Wed Jun 20, 2018 2:18 pm    Post subject: Reply with quote

There's no need to apologize. Everyone have their priorities, and life can easily get in the way of everything.

We're here to help (or at least try to) at your pace (when we're able to keep up with it, and our pace allows for it).

It might be more weird if troubleshooting things like this did /not/ get frustrating at some point. :]
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
Tyrus
Guru
Guru


Joined: 03 Feb 2018
Posts: 300

PostPosted: Wed Jun 20, 2018 7:03 pm    Post subject: Reply with quote

@Erdie:
As long as you stay with wine< 3.0.1 I doubt that gcc 7 will change much.

The stable version at WineHQ is still 3.0.1. If you use the gentoo stable version wine has problems with PIE host executables.
There is a bugreport: https://bugs.winehq.org/show_bug.cgi?id=43217

Caused by the profile change to 17.0 your system is using position independent code.

If you already tried the wine version 3.0.1 you never gave feedback about that. So I assume you never tried.
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Wed Jun 20, 2018 7:13 pm    Post subject: Reply with quote

Tyrus wrote:
@Erdie:
As long as you stay with wine< 3.0.1 I doubt that gcc 7 will change much.

The stable version at WineHQ is still 3.0.1. If you use the gentoo stable version wine has problems with PIE host executables.
There is a bugreport: https://bugs.winehq.org/show_bug.cgi?id=43217

Caused by the profile change to 17.0 your system is using position independent code.

If you already tried the wine version 3.0.1 you never gave feedback about that. So I assume you never tried.


I am using wine stable. If this is the case I will immediatly switch to wine 3.0.1 and test afterwards. Thanks!
But first I will perform the migration to gcc-7
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Thu Jun 21, 2018 6:03 am    Post subject: Reply with quote

Good new:

Yesterday evening I compiled gcc-7 and even more I switched to wine-staging-3.10 (unstable). Afterthat I tried to lauch Aerofly Professional Deluxe and it failed as usual :(

Then I started

Code:

emerge -ae --keep-going @world


about ~1200 packages

and now, early in the morning, I am testing to launch afpd works!! :D It startet but I will not fully test, need to go to work first. In the evening all packges will be almosts be compiled. An then lets see.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Fri Jun 22, 2018 6:21 am    Post subject: Reply with quote

Hi all,

compilation went through. Everything looks fine so far. My flying simulators are working. Steam games not yet tested. Wine is now wine staging. BTW I switched accidently to 2.21 and this works now, too. So the wine version had not impact on my problem. I looked like the gcc version was the devil. I will have further investigation and report.

-Erdie
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Erdie
Advocate
Advocate


Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany

PostPosted: Tue Jun 26, 2018 6:20 pm    Post subject: Reply with quote

I marked this thread as "FIXED" Many thanks to everyone for your great support!
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum