Keno
commented
8 years ago Closed Keno closed 8 years ago
Keno
commented
8 years ago Keno
commented
8 years ago Backtrace of the message complaining about the segfault:
1|debug > timejump e783545
We have arrived.
wine client error:28: write: Bad file descriptor
Stopped in function _raw_syscall
0x00007f058d103446<+33>: movq $582, %r11
0x00007f058d10344d<+40>: movq $-1, %rcx
=> 0x00007f058d103454<+47>: callq *32(%rsp)
0x00007f058d103458<+51>: xorl %ecx, %ecx
0x00007f058d10345a<+53>: movq $-1, %rcx
1|debug > bt
[1] _raw_syscall
[2] traced_raw_syscall
[3] syscall_hook
[4] _syscall_hook_trampoline
[5] _syscall_hook_trampoline_89_c2_f7_da
[6] pthread_sigmask
[7] wine_server_call
[8] NtCreateEvent
[9] UnhandledExceptionFilter
[10] __wine_exception_handler
[11] call_stack_handlers
[12] raise_exception
[13] raise_segv_exception
[14] raise_func_trampoline
[15] jl_get_global_for(char const*, void*, llvm::Module*)
[16] julia_gv(char const*, _jl_sym_t*, _jl_module_t*, void*)
[17] global_binding_pointer(_jl_module_t*, _jl_sym_t*, jl_binding_t**, bool, jl_codectx_t*)
[18] emit_getfield(_jl_value_t*, _jl_sym_t*, jl_codectx_t*)
[19] emit_expr(_jl_value_t*, jl_codectx_t*)
[20] emit_jlcall(llvm::Value*, llvm::Value*, _jl_value_t**, unsigned long long, jl_codectx_t*)
[21] emit_call(jl_expr_t*, jl_codectx_t*)
[22] emit_expr(_jl_value_t*, jl_codectx_t*)
[23] emit_condition(_jl_value_t*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, jl_codectx_t*)
[24] emit_expr(_jl_value_t*, jl_codectx_t*)
[25] emit_stmtpos(_jl_value_t*, jl_codectx_t*)
[26] emit_function(_jl_lambda_info_t*, _jl_llvm_functions_t*)
[27] jl_compile_linfo
[28] jl_compile_for_dispatch at /root/julia-win64-build/src/gf.c:1311
[29] jl_apply_generic at /root/julia-win64-build/src/julia_internal.h:184
[30] do_call at /root/julia-win64-build/src/interpreter.c:66
[31] eval at /root/julia-win64-build/src/interpreter.c:205
[32] do_call at /root/julia-win64-build/src/interpreter.c:65
[33] eval at /root/julia-win64-build/src/interpreter.c:205
[34] do_call at /root/julia-win64-build/src/interpreter.c:65
[35] eval at /root/julia-win64-build/src/interpreter.c:205
[36] eval at /root/julia-win64-build/src/interpreter.c:264
[37] eval_body at /root/julia-win64-build/src/interpreter.c:562
[38] jl_toplevel_eval_flex at /root/julia-win64-build/src/toplevel.c:552
[39] jl_parse_eval_all at /root/julia-win64-build/src/ast.c:717
[40] jl_load at /root/julia-win64-build/src/toplevel.c:596
[41] _julia_init at /root/julia-win64-build/src/init.c:687
[42] julia_init
[43] wmain at /root/julia-win64-build/ui/repl.c:236
[44] __tmainCRTStartup
[45] mainCRTStartup
[46] start_process
[47] call_thread_func
[48] call_thread_entry_point
[49] start_process
[50] wine_call_on_stack
[51] wine_switch_to_stack at ../../../wine/libs/wine/port.c:77
[52] LdrInitializeThunk
[53] __wine_kernel_init
[54] __wine_process_init
[55] wine_init at ../../../wine/libs/wine/loader.c:956
[56] wine client error:28: write: Bad file descriptor15|debug > rc
Stopped in function jl_get_global_for(char const*, void*, llvm::Module*)
0x0000000000d2f0d1<+241>: movb $0, 481(%rbp)
0x0000000000d2f0d8<+248>: movq $0, 488(%rbp)
=> 0x0000000000d2f0e3<+259>: movq 16(%rbx), %r12
0x0000000000d2f0e7<+263>: leaq 16(%rax), %rdx
0x0000000000d2f0eb<+267>: movq 24(%rbx), %rax
1|debug > reg rbx
0x0000000092630000Looks like it's trying to load the std::string vtable?
6f64f0a9: e8 8a 97 fe ff callq 6f638838 <_ZNSt8ios_baseC2Ev>
6f64f0ae: 48 8b 1d 1b 5d 0f 00 mov 0xf5d1b(%rip),%rbx # 6f744dd0 <__fu1__ZTTNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE>(gdb) p *(void**)0xe24dd0
$2 = (void *) 0x92630000gdb/rr is showing an access somewhere around e272653, Arsenic is having trouble with watchpoints for some reason, so don't have a backtrace yet.
Keno
commented
8 years ago In object file:
0x0000000000fba5bcFirst access:
1|debug > rsi
Stopped in function do_pseudo_reloc
0x0000000000d194d1<+502>: jmp 51
0x0000000000d194d3<+504>: movq -32(%rbp), %rax
=> 0x0000000000d194d7<+508>: movq (%rax), %rax
0x0000000000d194da<+511>: movq %rax, -48(%rbp)
0x0000000000d194de<+515>: jmp 39
1|debug > reg rax
0x0000000000e24dd0
1|debug > bt
[1] do_pseudo_reloc
[2] _pei386_runtime_relocator
[3] __DllMainCRTStartup
[4] DllMainCRTStartup
[5] MODULE_InitDLL
[6] process_attach.part.7
[7] process_attach.part.7
[8] attach_process_dlls
[9] wine_call_on_stack
[10] LdrInitializeThunk
[11] __wine_kernel_init
[12] __wine_process_init
[13] wine_init at ../../../wine/libs/wine/loader.c:956
[14] <Unknown Module>
1|debug > when
Ticks: 0x000000000081dbf4
Time: 272653Second/Third access:
Stopped in function __libc_freeres
0x00007f058c8b236a<+394>: movq (%rsi), %rsi
0x00007f058c8b236d<+397>: movq %rsi, (%rdi)
=> 0x00007f058c8b2370<+400>: movq %rcx, -8(%rdi,%rdx)
0x00007f058c8b2375<+405>: retq
0x00007f058c8b2376<+406>: nopw %cs:(%rax,%rax)
1|debug > bt
[1] __libc_freeres
[2] MSVCRT_memcpy
[3] __write_memory
[4] do_pseudo_reloc
[5] _pei386_runtime_relocator
[6] __DllMainCRTStartup
[7] DllMainCRTStartup
[8] MODULE_InitDLL
[9] process_attach.part.7
[10] process_attach.part.7
[11] attach_process_dlls
[12] wine_call_on_stack
[13] LdrInitializeThunk
[14] __wine_kernel_init
[15] __wine_process_init
[16] wine_init at ../../../wine/libs/wine/loader.c:956
[17] <Unknown Module>
1|debug > rsi
Stopped in function __libc_freeres
0x00007f058c8b2365<+389>: movq -8(%rsi,%rdx), %rcx
0x00007f058c8b236a<+394>: movq (%rsi), %rsi
=> 0x00007f058c8b236d<+397>: movq %rsi, (%rdi)
0x00007f058c8b2370<+400>: movq %rcx, -8(%rdi,%rdx)
0x00007f058c8b2375<+405>: retq
1|debug > reg rsi
0x0000000092630000
1|debug > reg rdi
0x0000000000e24dd0
1|debug > when
Ticks: 0x000000000081dbff
Time: 272653The second part os obviously suspicious. __libc_freeres, shouldn't be called, so something else is going wrong (or that's not __libc_freeres and the symblication is wrong, that's possible too).
Keno
commented
8 years ago Ok, does seem to be a symbolication problem. GDB thinks:
0x7f058c8b236d <__memmove_avx_unaligned+397> mov %rsi,(%rdi)
0x7f058c8b2370 <__memmove_avx_unaligned+400> mov %rcx,-0x8(%rdi,%rdx,1)
0x7f058c8b2375 <__memmove_avx_unaligned+405> retqPerhaps time to build wine with debug info and step through the relocator.
Keno
commented
8 years ago Oh, huh, do_pseudo_reloc seems to be a mingw thing not a wine thing.
Ok, debug version of wine is all good to go. New spacetime coordinates:
e6792610xe24dd0 (didn't change)e272320Keno
commented
8 years ago Looking at the pseudo relocations in libjulia.dll:
julia> COFF.dump_pseudo_relocs(h)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5e4,0x001c4eb0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5bc,0x001c4dd0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a404,0x001c5060,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b034,0x001c4dc0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b024,0x001c4da0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b02c,0x001c4db0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b4f4,0x001c4e20,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5dc,0x001c4ea0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5ec,0x001c4ec0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5c4,0x001c4de0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b4fc,0x001c4e30,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a60c,0x001c4f00,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5f4,0x001c4ed0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a604,0x001c4ef0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5d4,0x001c4e00,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5fc,0x001c4ee0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5cc,0x001c4df0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a614,0x001c4f10,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b524,0x001c4e80,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b4ec,0x001c4e10,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b51c,0x001c4e70,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035ae14,0x001c4d90,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b504,0x001c4e40,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b534,0x001c4fe0,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b50c,0x001c4e50,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b514,0x001c4e60,0x00000040)
item = COFF.runtime_pseudo_reloc_item_v2(0x0035b52c,0x001c4e90,0x00000040)I'm gonna go ahead and guess that
item = COFF.runtime_pseudo_reloc_item_v2(0x0035a5bc,0x001c4dd0,0x00000040)is the one in question, which would put the import slot at
0x0035a5bc + (0xe24dd0-0x001c4dd0) == 0x00fba5bcwhich was the address that was at that slot, before? Weird, but looking at the relocation code, that seems like the way it's supposed to be:
/* Adjust the relocation value */
reldata -= ((ptrdiff_t) base + r->sym);
reldata += addr_imp;Ok, so it does look like mingw is simply copying what the wine dyld is putting there:
julia> Gallium.load(sess, RemotePtr{UInt64}(0x0000000000fba5bc))
0x0000000092630000(this is at the first load of that address). Let's see where that comes from.
Keno
commented
8 years ago Most recent reference:
1|debug > rc
Stopped in function import_dll
0x000000007bc5efbc<+1488>: movq -184(%rbp), %rdi
0x000000007bc5efc3<+1495>: callq -1792
=> 0x000000007bc5efc8<+1500>: movq %rax, (%r15)
0x000000007bc5efcb<+1503>: testq %rax, %rax
0x000000007bc5efce<+1506>: jne 107
1|debug > reg rax
0x0000000092630000
1|debug > reg r15
0x0000000000fba5bc
1|debug > when
Ticks: 0x000000000032e72e
Time: 245981I'm a little confused why I don't have debuginfo though, since I rebuilt with debuginfo.
Keno
commented
8 years ago Ok, fixed in Gallium:
In loader.c:566
681 pe_name = get_rva( module, (DWORD)import_list->u1.AddressOfData );
682 thunk_list->u1.Function = (ULONG_PTR)find_named_export( imp_mod, exports, exp_size,
683 (const char*)pe_name->Name,
684 pe_name->Hint, load_path );
1|debug > bt
[1] import_dll at ../../../wine/dlls/ntdll/loader.c:682
[2] fixup_imports at ../../../wine/dlls/ntdll/loader.c:915
[3] load_native_dll at ../../../wine/dlls/ntdll/loader.c:1821
[4] load_dll at ../../../wine/dlls/ntdll/loader.c:2299
[5] import_dll at ../../../wine/dlls/ntdll/loader.c:601
[6] fixup_imports at ../../../wine/dlls/ntdll/loader.c:915
[7] LdrInitializeThunk at ../../../wine/dlls/ntdll/loader.c:3095
[8] __wine_kernel_init at ../../../wine/dlls/kernel32/process.c:13021|C++ > (char*)pe_name->Name
(char *) "_ZTTNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE"Ok, so it's trying to import that symbol from:
(rr) p (char*)get_rva(module, exports->Name)
$17 = 0x2384d1e "libstdc++-6.dll"which seems to be loaded at
0226f000-02270000 ---p 00000000 00:00 0
02270000-02271000 r-xp 00000000 fd:01 1750027 /root/.local/share/rr/make-5/mmap_hardlink_20030_libstdc++-6.dll
02271000-02340000 r-xp 00000000 00:00 0
02340000-02344000 rwxp 00000000 00:00 0
02344000-02376000 r-xp 00000000 00:00 0
02376000-02378000 rwxp 00000000 00:00 0
02378000-023c4000 r-xp 00000000 00:00 0
023c4000-023c7000 rwxp 00000000 00:00 0
023c7000-023c8000 rwxp 00150000 fd:01 1750027 /root/.local/share/rr/make-5/mmap_hardlink_20039_libstdc++-6.dll
023c8000-02a17000 r-xp 00000000 00:00 0
02a17000-02a59000 r-xp 0079e000 fd:01 1750027 /root/.local/share/rr/make-5/mmap_hardlink_20043_libstdc++-6.dll
02a59000-02ad6000 r-xp 00000000 00:00 0
02ad6000-02b1e000 r-xp 0085c000 fd:01 1750027 /root/.local/share/rr/make-5/mmap_hardlink_20045_libstdc++-6.dllWell, I understand why it's doing what it's doing:
Export {
Ordinal: 4931
Name: _ZTSy
RVA: 0x903C0000
}
Export {
Ordinal: 4932
Name: _ZTTNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE
RVA: 0x903C0000
}Don't know yet what it's supposed to be doing though.
Keno
commented
8 years ago Well, Wine appears to be doing everything correctly. If I move the stdc++-6.dll from my linux box to the windows box everything crashes in the same place. Unfortunately, that must mean that something is bust about my toolchain, which is unfortunate, because I just followed the cross compile instructions.
Keno
commented
8 years ago My latest theory is that this is the ABI tags disaster, somehow exposed trough a not-up-to-date .def file, but we'll see.
Keno
commented
8 years ago link line:
libtool: link: /root/mingw-w64-dgn/build/bc_gcc/./gcc/xgcc -shared-libgcc -B/root/mingw-w64-dgn/build/bc_gcc/./gcc -nostdinc++ -L/root/mingw-w64-dgn/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src -L/root/mingw-w64-dgn/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/root/mingw-w64-dgn/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/root/mingw-w64-dgn/cross/x86_64-w64-mingw32/lib -L/root/mingw-w64-dgn/cross/mingw/lib -isystem /root/mingw-w64-dgn/cross/x86_64-w64-mingw32/include -isystem /root/mingw-w64-dgn/cross/mingw/include -B/root/mingw-w64-dgn/cross/x86_64-w64-mingw32/bin/ -B/root/mingw-w64-dgn/cross/x86_64-w64-mingw32/lib/ -isystem /root/mingw-w64-dgn/cross/x86_64-w64-mingw32/include -isystem /root/mingw-w64-dgn/cross/x86_64-w64-mingw32/sys-include -shared -nostdlib /root/mingw-w64-dgn/cross/x86_64-w64-mingw32/lib/dllcrt2.o /root/mingw-w64-dgn/build/bc_gcc/./gcc/crtbegin.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive -L/root/mingw-w64-dgn/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs -L/root/mingw-w64-dgn/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src -L/root/mingw-w64-dgn/build/bc_gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/root/mingw-w64-dgn/cross/x86_64-w64-mingw32/lib -L/root/mingw-w64-dgn/cross/mingw/lib -L/root/mingw-w64-dgn/build/bc_gcc/./gcc -L/root/mingw-w64-dgn/cross/x86_64-w64-mingw32/bin -L/root/mingw-w64-dgn/cross/mingw/lib/../lib -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt /root/mingw-w64-dgn/build/bc_gcc/./gcc/crtend.o -Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver -o .libs/libstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libstdc++.dll.a
tkelman
commented
8 years ago Which cross compile instructions? Exactly what gcc version did you use, and with what configure flags?
Keno
commented
8 years ago ~/cross-w64/bin/x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=/root/cross-w64/bin/x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/root/cross-w64/bin/../libexec/gcc/x86_64-w64-mingw32/6.1.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: /root/mingw-w64-dgn/source/gcc-6.1.0/configure --target=x86_64-w64-mingw32 --disable-nls --disable-multilib --with-gmp=/root/mingw-w64-dgn/build/for_cross --with-mpfr=/root/mingw-w64-dgn/build/for_cross --with-mpc=/root/mingw-w64-dgn/build/for_cross --with-isl=/root/mingw-w64-dgn/build/for_cross --enable-languages=c,c++,objc,obj-c++,fortran --disable-libstdcxx-pch --prefix=/root/mingw-w64-dgn/cross --with-sysroot=/root/mingw-w64-dgn/cross
Thread model: win32
gcc version 6.1.0 (GCC)I see this too with i686-w64-mingw32, and I think it's more likely a GCC 5+ issue, not a Wine issue.
Keno
commented
8 years ago Yes, something is awry in gcc land.
Keno
commented
8 years ago Though the opensuse-built libstdc++-6.dll library seems fine, so something else is up.
tkelman
commented
8 years ago I suspect it works on 64 bit but not 32, and the difference might be that its libstdc++ was built with --enable-fully-dynamic-string which is an ABI difference. 4.9.2-2 from Cygwin works on both 32 and 64 bit, but the maintainer just uploaded 5.4.0-1 and 5.4.0-2 (the latter of which works on 64 bit but not 32) so you can't get 4.9.2-2 any more. I might upload my local copies to S3 so we have a backup available, along with modified setup.ini's if the maintainer doesn't get 4.9.2-2 reinstated as prev like I've asked him to.
Keno
commented
8 years ago I suspect it works on 64 bit but not 32
Not sure what you're saying, I'm building x86_64 binaries.
tkelman
commented
8 years ago Sure, but if you were building i686 binaries then the opensuse gcc 6.1 toolchain is also broken right now.
Keno
commented
8 years ago I'll try rebuilding with my cross compiler with --enable-fully-dynamic-string and see if that hides the segfault.
Keno
commented
8 years ago Doesn't seem to made a difference :(
Keno
commented
8 years ago I built a new GNU ld from trunk and it does not exhibit this problem (when built with -O0 at least).
Keno
commented
8 years ago I can however, reproduce this with binutils 2.26. Will bisect the linker to determine what the fix was and make sure it's adequately regression tested upstream (i.e. not an accidental rearrangement that could reoccur).
Keno
commented
8 years ago Apparently fixed by:
commit 4153b6dbb0f38a16fd5b583761aa811212fbb9a5
Author: Nick Clifton <nickc@redhat.com>
Date: Tue Mar 22 12:25:08 2016 +0000
Improve COFF/PE linker garbage collection by preventing the removal of sections containing exported symbols.
PR ld/19803
* ldlang.c (lang_add_gc_name): New function. Adds the provided
symbol name to the list of gc symbols.
(lang_process): Call lang_add_gc_name with entry_symbol_default if
entry_symbol.name is NULL. Use lang_add_gc_name to add the init
and fini function names.
* pe-dll.c (process_def_file_and_drectve): Add exported names to
the gc symbol list.
* testsuite/ld-pe/pr19803.s: Do not export _testval symbol.
* testsuite/ld-pe/pr19803.d: Tweak expected output.So we need to make sure that all windows builds use binutils >= 2.27 (gc-sections may be a newish feature so older binutils are probably ok as well) or we leave a minefield of invalid export tables in our shared libaries.
Keno
commented
8 years ago Also cross reference to the thread where this was originally reported: https://sourceware.org/ml/binutils/2016-03/msg00112.html
Keno
commented
8 years ago Gonna close this issue since there is an upstream release that fixes it, but something to keep in mind for releases, etc.
tkelman
commented
8 years ago The opensuse cross-binutils has been applying several related patches already though. https://build.opensuse.org/package/show/windows:mingw:win64/mingw64-binutils https://build.opensuse.org/package/show/windows:mingw:win32/mingw32-binutils
Keno
commented
8 years ago Right, as a I said, I couldn't reproduce this with the opensuse binaries. If yours was with those binaries, you may have to provide more details so I can take a look.
tkelman
commented
8 years ago Do an i686 build.
Keno
commented
8 years ago Ok, will try.