64bit winelib test app fails on AMD CPU, but works on Intel - need help to identify possible problem, please :)
Hey List, A few days ago, i posted to the list about possibly porting a winelib app to support x86_64. (currently supports x86). the original post is here (for those interested, but not entirely relevant to this post): http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to-... moving on. So we have a simple test app, that successfully loads 64bit DLLs on my friend's Intel based machines, while on my AMD Phenom II 965 X4 - the code fails. -> Successful on Intel: xj(a)xj:~/Muzyka/fsthost/trunk$ ./test64.exe ../../VST/ColourEQ_64.dll Load plugin ../../VST/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close So intel computers tested (2 that i know of) work just fine. -> Failure on AMD: http://pastebin.com/x64pig3s and a little snippet: ./test64.exe '/home/ninez/Desktop/ColourEQ_64.dll' fixme:heap:HeapSetInformation 0x2c4000 0 0x23fce0 4 Load plugin /home/ninez/Desktop/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3d4000 0 0x23f5f0 4 Main entry: 0x1800077d0 Revive plugin wine: Unhandled page fault on read access to 0xffffffff at address 0xffffffff (thread 002a), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module <snip> fixme:dbghelp:elf_search_auxv can't find symbol in module Unhandled exception: page fault on read access to 0xffffffff in 64-bit code (0x00000000ffffffff). fixme:dbghelp:elf_search_auxv can't find symbol in module Register dump: rip:00000000ffffffff rsp:000000000023fa78 rbp:000000000023fbd0 eflags:00010246 ( R- -- I Z- -P- ) rax:00000000003d8de0 rbx:0000000000000000 rcx:0000000000000000 rdx:0000000000000001 rsi:00000000ffffffff rdi:00007f1205f559d0 r8:0000000000000000 r9:0000000000000000 r10:0000000000000001 r11:0000000000000000 r12:0000000000000000 r13:00007f1205f50040 r14:000000007b86f920 r15:00007fffffbe8000 Stack dump: 0x000000000023fa78: 0000000180007756 00000000003d8de0 0x000000000023fa88: 00007f1206ff14d3 0000000000010ac1 0x000000000023fa98: 000000000000000d 0000000000000000 0x000000000023faa8: 00007f1200000000 fffffffffffffffe 0x000000000023fab8: 000000000023fbd0 00007f1205f559d0 0x000000000023fac8: 00007f1205f55b09 2020202020202020 0x000000000023fad8: 0000000000010ac1 00007f1207324323 0x000000000023fae8: 0000000000002000 ffff00ffffffffff 0x000000000023faf8: ffff00ffffffffff 0000000000202020 0x000000000023fb08: 00000001800077d0 0000000180000000 0x000000000023fb18: 0000000000010ac1 5b5b5b5b5b5b5b5b 0x000000000023fb28: 5b5b5b5b5b5b5b5b 2020202020202020 It's odd that it is working on Intel H/W, but not my AMD system. ~ what could be a possible reason for this? We've made s simple test app that doesn't require jackd, or FSThost functions, to simplify things. The source code can be found here: https://sourceforge.net/p/fsthost/code/171/tree/ SVN code required: svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code the test app source code is called 'test64-most-simple.c' The test app can be compiled with; $ make -f Makefile64-most-simple then $ ./test64.exe /path/to/64bitVST a tester can be found here: http://www.ddmf.eu/freeware.php grab 'ColourEQ' (contains both 32bit and 64bit versions... and obviously use the 64bit version to try/test.) anyway, i am not sure what the problem is, maybe someone here has an idea or two? ... i've been wondering if there is some sort of misalignment/compiler issue, that is causing the problem...but i want to rule out Wine64 being an issue, first - if possible. any help is appreciated. Thanks Jordan
On Thu, Apr 4, 2013 at 6:39 PM, jordan <triplesquarednine(a)gmail.com> wrote:
Hey List,
A few days ago, i posted to the list about possibly porting a winelib app to support x86_64. (currently supports x86).
the original post is here (for those interested, but not entirely relevant to this post):
http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to-...
moving on.
So we have a simple test app, that successfully loads 64bit DLLs on my friend's Intel based machines, while on my AMD Phenom II 965 X4 - the code fails.
-> Successful on Intel:
xj(a)xj:~/Muzyka/fsthost/trunk$ ./test64.exe ../../VST/ColourEQ_64.dll Load plugin ../../VST/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close
So intel computers tested (2 that i know of) work just fine.
-> Failure on AMD: http://pastebin.com/x64pig3s and a little snippet:
./test64.exe '/home/ninez/Desktop/ColourEQ_64.dll' fixme:heap:HeapSetInformation 0x2c4000 0 0x23fce0 4 Load plugin /home/ninez/Desktop/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3d4000 0 0x23f5f0 4 Main entry: 0x1800077d0 Revive plugin wine: Unhandled page fault on read access to 0xffffffff at address 0xffffffff (thread 002a), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module
<snip>
fixme:dbghelp:elf_search_auxv can't find symbol in module Unhandled exception: page fault on read access to 0xffffffff in 64-bit code (0x00000000ffffffff). fixme:dbghelp:elf_search_auxv can't find symbol in module Register dump: rip:00000000ffffffff rsp:000000000023fa78 rbp:000000000023fbd0 eflags:00010246 ( R- -- I Z- -P- ) rax:00000000003d8de0 rbx:0000000000000000 rcx:0000000000000000 rdx:0000000000000001 rsi:00000000ffffffff rdi:00007f1205f559d0 r8:0000000000000000 r9:0000000000000000 r10:0000000000000001 r11:0000000000000000 r12:0000000000000000 r13:00007f1205f50040 r14:000000007b86f920 r15:00007fffffbe8000 Stack dump: 0x000000000023fa78: 0000000180007756 00000000003d8de0 0x000000000023fa88: 00007f1206ff14d3 0000000000010ac1 0x000000000023fa98: 000000000000000d 0000000000000000 0x000000000023faa8: 00007f1200000000 fffffffffffffffe 0x000000000023fab8: 000000000023fbd0 00007f1205f559d0 0x000000000023fac8: 00007f1205f55b09 2020202020202020 0x000000000023fad8: 0000000000010ac1 00007f1207324323 0x000000000023fae8: 0000000000002000 ffff00ffffffffff 0x000000000023faf8: ffff00ffffffffff 0000000000202020 0x000000000023fb08: 00000001800077d0 0000000180000000 0x000000000023fb18: 0000000000010ac1 5b5b5b5b5b5b5b5b 0x000000000023fb28: 5b5b5b5b5b5b5b5b 2020202020202020
It's odd that it is working on Intel H/W, but not my AMD system. ~ what could be a possible reason for this?
We've made s simple test app that doesn't require jackd, or FSThost functions, to simplify things.
The source code can be found here: https://sourceforge.net/p/fsthost/code/171/tree/ SVN code required: svn checkout svn://svn.code.sf.net/p/fsthost/code/trunk fsthost-code
the test app source code is called 'test64-most-simple.c'
The test app can be compiled with;
$ make -f Makefile64-most-simple
then
$ ./test64.exe /path/to/64bitVST
a tester can be found here: http://www.ddmf.eu/freeware.php
grab 'ColourEQ' (contains both 32bit and 64bit versions... and obviously use the 64bit version to try/test.)
anyway, i am not sure what the problem is, maybe someone here has an idea or two? ... i've been wondering if there is some sort of misalignment/compiler issue, that is causing the problem...but i want to rule out Wine64 being an issue, first - if possible.
any help is appreciated. Thanks
Jordan
Are y'all using the same OS/distro/kernel/gcc/libc versions? -- -Austin
Hey Austin
Are y'all using the same OS/distro/kernel/gcc/libc versions?
Different (distro) but everything else is very similar, if not the same. My feeling is that this is not going to end up being the problem and if i remember correctly, the 2 Intel systems are not the same either.. But just to make sure that isn't the case - I am installing a VM to test with (to match his system)... any other ideas, suggestions beyond that (?) cheerz
Am 05.04.2013 02:06, schrieb jordan:
Hey Austin
Are y'all using the same OS/distro/kernel/gcc/libc versions?
Different (distro) but everything else is very similar, if not the same. My feeling is that this is not going to end up being the problem and if i remember correctly, the 2 Intel systems are not the same either..
But just to make sure that isn't the case - I am installing a VM to test with (to match his system)...
any other ideas, suggestions beyond that (?)
was it the same binary or did you compiled it on each cpu? Do you have the same Wine versions?
Hey Andre,
was it the same binary or did you compiled it on each cpu? Do you have the same Wine versions?
Compiled on each respective system. (no sharing of binaries). It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27). On intel systems, it works on ALL versions. On my AMD system, it doesn't work at all. cheerz Jordan
Am 05.04.2013 02:36, schrieb jordan:
Hey Andre,
was it the same binary or did you compiled it on each cpu? Do you have the same Wine versions?
Compiled on each respective system. (no sharing of binaries).
It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27). On intel systems, it works on ALL versions. On my AMD system, it doesn't work at all.
only thing that comes to mind is that you need gcc>=4.4, but configure checks that for you. Did you tried the binaries of your intel mate?
Hey Andre.
only thing that comes to mind is that you need gcc>=4.4, but configure checks that for you. Did you tried the binaries of your intel mate?
Well, i am using gcc-4.8 (but have also tested with gcc-4.7.3/4). He is using gcc 4.7.3 or .4. No, i did not try his binaries ~ but that is worth having a look, even though it wouldn't solve the issue really... I'm also in the middle of setting a VM, to see if it works in there, maybe then i can rule that out (for sure). thanks Jordan
On Fri, Apr 5, 2013 at 3:36 AM, jordan <triplesquarednine(a)gmail.com> wrote:
It's been tested with several wine versions (1.4.1, 1.5.24, 1.5.27). On intel systems, it works on ALL versions. On my AMD system, it doesn't work at all.
Hello! Works fine on my AMD system: vinis(a)g44:/media/vinis/code/temp/fsthost-code$ WINEPREFIX=/media/vinis/bottles/test64 ./test64.exe ../ColourEQ_64.dll Load plugin ../ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close gcc 4.7.2; wine 1.5.27; -- Gediminas Jakutis LDK Varčiai www.varciai.lt
Hello!
Hey Gediminas! ;)
Works fine on my AMD system:
Can you also give me the rest of your specs / distro, please?
vinis(a)g44:/media/vinis/code/temp/fsthost-code$ WINEPREFIX=/media/vinis/bottles/test64 ./test64.exe ../ColourEQ_64.dll Load plugin ../ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close
gcc 4.7.2; wine 1.5.27;
great news that it worked, not so great news that i need to find what the issue is on my machine ;) thanks Jordan
On Thu, Apr 04, 2013 at 07:39:16PM -0400, jordan wrote:
Hey List,
A few days ago, i posted to the list about possibly porting a winelib app to support x86_64. (currently supports x86).
the original post is here (for those interested, but not entirely relevant to this post): http://wine.1045685.n5.nabble.com/exploring-possibly-porting-winelib-app-to-...
moving on.
So we have a simple test app, that successfully loads 64bit DLLs on my friend's Intel based machines, while on my AMD Phenom II 965 X4 - the code fails.
-> Successful on Intel:
xj(a)xj:~/Muzyka/fsthost/trunk$ ./test64.exe ../../VST/ColourEQ_64.dll Load plugin ../../VST/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3c4000 0 0x22f610 4 Main entry: 0x1800077d0 Revive plugin V: 66048 U: 1131365713 NI: 2 NO: 2 NPr: 10 NPa: 42 Open Close
So intel computers tested (2 that i know of) work just fine.
-> Failure on AMD: http://pastebin.com/x64pig3s and a little snippet:
./test64.exe '/home/ninez/Desktop/ColourEQ_64.dll' fixme:heap:HeapSetInformation 0x2c4000 0 0x23fce0 4 Load plugin /home/ninez/Desktop/ColourEQ_64.dll fixme:heap:HeapSetInformation 0x3d4000 0 0x23f5f0 4 Main entry: 0x1800077d0 Revive plugin wine: Unhandled page fault on read access to 0xffffffff at address 0xffffffff (thread 002a), starting debugger... fixme:dbghelp:elf_search_auxv can't find symbol in module
Works for me on my AMD Phenom(tm) II X4 945 Processor. It looks like the struct AEffect* plugin = main_entry((audioMasterCallback) simple_master_callback); returns 0xffffffff, which is probably a failure indication. Can you add a printf("plugin %p\n", plugin); after above line? I would suspect things like: - checks for processor features and returns 0xffffffff if not found. CIao, Marcus
Hey Marcus
Works for me on my AMD Phenom(tm) II X4 945 Processor.
great :) (very similar CPU).
It looks like the struct AEffect* plugin = main_entry((audioMasterCallback) simple_master_callback);
returns 0xffffffff, which is probably a failure indication.
Can you add a printf("plugin %p\n", plugin); after above line?
I would suspect things like: - checks for processor features and returns 0xffffffff if not found.
This makes sense. Unfortunately, i won't be able to test until later (i'm at work). Thanks for your tips ~ very useful stuff! Jordan
CIao, Marcus
Hey Marcus,
Can you add a printf("plugin %p\n", plugin); after above line?
I would suspect things like: - checks for processor features and returns 0xffffffff if not found.
I added this line to the sources / compiled and tested - here is output: http://pastebin.com/QMtWttRZ I'n not sure what to make of it. I've been trying to nail down what the problem might be on my system (to no avail). It's really strange... I've tried different kernels, different versions of wine, using a binary version of the test app (not compiled on my machine). but nothing seems to work. Jordan
Hi, Well, your testcase had a trivial mistake which i now see. This line: typedef struct AEffect * (*main_entry_t)(audioMasterCallback); must read: typedef struct WINAPI AEffect * (*main_entry_t)(audioMasterCallback); WINAPI is critical here, as it changes the call from the SysV AMD64 calling convention to the Microsoft x64 one which is entirely different. (That it works for 32bit is probably just luck.) If you fix it in fst.h: fst.h:typedef struct AEffect * (*main_entry_t)(audioMasterCallback); It will probably also work better. Ciao, Marcus On Sat, Apr 06, 2013 at 06:41:42PM -0400, jordan wrote:
Hey Marcus,
Can you add a printf("plugin %p\n", plugin); after above line?
I would suspect things like: - checks for processor features and returns 0xffffffff if not found.
I added this line to the sources / compiled and tested - here is output: http://pastebin.com/QMtWttRZ
I'n not sure what to make of it. I've been trying to nail down what the problem might be on my system (to no avail). It's really strange...
I've tried different kernels, different versions of wine, using a binary version of the test app (not compiled on my machine). but nothing seems to work.
Jordan
participants (5)
-
André Hentschel -
Austin English -
Gediminas Jakutis -
jordan -
Marcus Meissner