-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Commit
…her than every object (fix #10898)
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
@@ -184,6 +184,7 @@ typedef struct _gcval_t { | |||||||||
|
||||||||||
#define GC_PAGE_LG2 14 // log2(size of a page) | ||||||||||
#define GC_PAGE_SZ (1 << GC_PAGE_LG2) // 16k | ||||||||||
#define GC_PAGE_OFFSET (16 - (sizeof(jl_taggedvalue_t) % 16)) | ||||||||||
|
||||||||||
// pool page metadata | ||||||||||
typedef struct _gcpage_t { | ||||||||||
|
@@ -219,7 +220,7 @@ typedef struct { | |||||||||
char pages[REGION_PG_COUNT][GC_PAGE_SZ]; // must be first, to preserve page alignment | ||||||||||
uint32_t freemap[REGION_PG_COUNT/32]; | ||||||||||
gcpage_t meta[REGION_PG_COUNT]; | ||||||||||
} region_t; | ||||||||||
} region_t __attribute__((aligned(GC_PAGE_SZ))); | ||||||||||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
Author
Member
|
#if !defined(_COMPILER_MICROSOFT_) | |
int _dummy[0]; | |
#endif |
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
May 3, 2015
Author
Member
gdb can manage it by calling p sizeof(buff_t)
. perhaps msvc can do the same? otherwise, you have to write a stub function that returns that value and call it in the debugger at runtime.
i just checked setjmp.h in my local msvc crt folder and see that the specification _CRT_ALIGN(16)
is present
that's a 0-byte array, it shouldn't make any difference.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 3, 2015
Contributor
(29dc.1b80): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for d:\code\msys64\home\Tony\julia\usr\bin\libjulia.dll
libjulia!jl_setjmp+0x3b:
000007fe`e0bd4f1b 0f297160 movaps xmmword ptr [rcx+60h],xmm6 ds:00000000`0f0500c8=00000000000000000000000000000000
0:000> ?? sizeof(buff_t)
unsigned int64 8
0:000> ?? sizeof(gcval_t)
unsigned int64 8
0:000> ?? sizeof(bigval_t)
unsigned int64 0x20
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
May 3, 2015
Author
Member
Can you walk up the stack frames and determine why that element is misaligned?
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 3, 2015
Contributor
With sufficient guidance, maybe. Will you be on IRC in about an hour?
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 4, 2015
Contributor
this useful at all?
(3ac.1d80): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for d:\code\msys64\home\Tony\julia\usr\bin\libjulia.dll
libjulia!jl_setjmp+0x3b:
000007fe`e22952bb 0f297160 movaps xmmword ptr [rcx+60h],xmm6 ds:00000000`0f0500c8=00000000000000000000000000000000
0:000> k
Child-SP RetAddr Call Site
00000000`009ced28 000007fe`e22575a4 libjulia!jl_setjmp+0x3b
00000000`009ced30 000007fe`e2256777 libjulia!ctx_switch+0x34 [d:\code\msys64\home\tony\julia\src\task.c @ 295]
00000000`009ced70 00000000`00c4f9ab libjulia!jl_switchto+0x97 [d:\code\msys64\home\tony\julia\src\task.c @ 372]
00000000`009cedb0 000007fe`e2174ab9 0xc4f9ab
00000000`009cede0 000007fe`e2174e84 libjulia!jl_apply+0x29 [d:\code\msys64\home\tony\julia\src\julia.h @ 1277]
00000000`009cee10 000007fe`e2167b49 libjulia!jl_trampoline+0x44 [d:\code\msys64\home\tony\julia\src\builtins.c @ 1027]
00000000`009cee50 000007fe`e2167ede libjulia!jl_apply+0x29 [d:\code\msys64\home\tony\julia\src\julia.h @ 1277]
00000000`009cee80 00000000`00c3f09f libjulia!jl_apply_generic+0x21e [d:\code\msys64\home\tony\julia\src\gf.c @ 1720]
00000000`009cef00 00000000`00c4ec70 0xc3f09f
00000000`009cefc0 00000000`00c4f793 0xc4ec70
00000000`009cf140 00000000`00c4e556 0xc4f793
00000000`009cf2e0 00000000`00c4e46e 0xc4e556
00000000`009cf360 00000000`00c4e3c0 0xc4e46e
00000000`009cf3d0 00000000`00c4e30b 0xc4e3c0
00000000`009cf430 000007fe`e2174ab9 0xc4e30b
00000000`009cf460 000007fe`e2174e84 libjulia!jl_apply+0x29 [d:\code\msys64\home\tony\julia\src\julia.h @ 1277]
00000000`009cf490 000007fe`e2167b49 libjulia!jl_trampoline+0x44 [d:\code\msys64\home\tony\julia\src\builtins.c @ 1027]
00000000`009cf4d0 000007fe`e2167e13 libjulia!jl_apply+0x29 [d:\code\msys64\home\tony\julia\src\julia.h @ 1277]
00000000`009cf500 00000000`00c3c091 libjulia!jl_apply_generic+0x153 [d:\code\msys64\home\tony\julia\src\gf.c @ 1696]
00000000`009cf580 00000000`00c3ad7f 0xc3c091
0:000> .f+
01 00000000`009ced30 000007fe`e2256777 libjulia!ctx_switch+0x34 [d:\code\msys64\home\tony\julia\src\task.c @ 295]
0:000> .f-
00 00000000`009ced28 000007fe`e22575a4 libjulia!jl_setjmp+0x3b
0:000> u
libjulia!jl_setjmp+0x3b:
000007fe`e22952bb 0f297160 movaps xmmword ptr [rcx+60h],xmm6
000007fe`e22952bf 0f297970 movaps xmmword ptr [rcx+70h],xmm7
000007fe`e22952c3 440f298180000000 movaps xmmword ptr [rcx+80h],xmm8
000007fe`e22952cb 440f298990000000 movaps xmmword ptr [rcx+90h],xmm9
000007fe`e22952d3 440f2991a0000000 movaps xmmword ptr [rcx+0A0h],xmm10
000007fe`e22952db 440f2999b0000000 movaps xmmword ptr [rcx+0B0h],xmm11
000007fe`e22952e3 440f29a1c0000000 movaps xmmword ptr [rcx+0C0h],xmm12
000007fe`e22952eb 440f29a9d0000000 movaps xmmword ptr [rcx+0D0h],xmm13
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
May 4, 2015
Author
Member
not much. i'm interested in why the GC might have been handing out an unaligned address, since nothing about this change should have been compiler-specific. what is the address of the jl_task_t
that contained the jl_jmp_buf
and what is offsetof(jl_task_t, ctx)
?
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 4, 2015
Contributor
0:000> ?? jl_current_task
struct _jl_task_t * 0x00000000`0f050018
+0x000 parent : 0x00000000`0f050018 _jl_task_t
+0x008 last : 0x00000000`0f050018 _jl_task_t
+0x010 tls : 0x00000000`11636438 _jl_value_t
+0x018 state : 0x00000000`00db4c60 _jl_sym_t
+0x020 consumers : 0x00000000`0f028018 _jl_value_t
+0x028 donenotify : 0x00000000`0f028018 _jl_value_t
+0x030 result : 0x00000000`0f028018 _jl_value_t
+0x038 exception : 0x00000000`0f028018 _jl_value_t
+0x040 start : (null)
+0x050 ctx : [16] _SETJMP_FLOAT128
+0x150 bufsz : 0
+0x158 stkbuf : (null)
+0x160 ssize : 0
+0x168 eh : 0x00000000`009cefe0 _jl_handler_t
+0x170 gcstack : (null)
+0x178 current_module : 0x00000000`0f058018 _jl_module_t
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 4, 2015
Contributor
I might not have 634c9ac applied locally, will rebuild again
edit: no change
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
May 4, 2015
Author
Member
that patch is not correct (https://msdn.microsoft.com/en-us/library/6ewkz86d.aspx). but also not relevant here
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
May 4, 2015
Author
Member
Line 825 in 053780d
DLLEXPORT jl_task_t *jl_new_task(jl_function_t *start, size_t ssize) |
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 4, 2015
Contributor
side note: should allocobj
probably be named jl_allocobj
, considering it's exported?
It looks like it's the removal of the realign16
element from the jl_taggedvalue_t
struct that causes the issue, and either this alignment of region_t
is really critical or there's some other compiler-dependent alignment behavior that this change is relying on.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 4, 2015
Contributor
Might also be a consequence of 4c06a18
I guess I could try putting back the realign16
element only for msvc
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 13, 2015
Contributor
Any ideas on the alignment issue? If I try to add back the padding fields only in the MSVC case, but without selectively reverting any other parts of this commit, I get a gc access violation while compiling inference (probably not surprising?)
osutils.jl
Please submit a bug report with steps to reproduce this fault, and any error mes
sages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION at 0x7fedf1c3dd8 -- gc_setmark_pool at d:\
code\msys64\home\tony\julia\src\gc.c:601
gc_setmark_pool at d:\code\msys64\home\tony\julia\src\gc.c:601
push_root at d:\code\msys64\home\tony\julia\src\gc.c:1653
gc_push_root at d:\code\msys64\home\tony\julia\src\gc.c:1470
push_root at d:\code\msys64\home\tony\julia\src\gc.c:1739
gc_push_root at d:\code\msys64\home\tony\julia\src\gc.c:1470
push_root at d:\code\msys64\home\tony\julia\src\gc.c:1689
gc_push_root at d:\code\msys64\home\tony\julia\src\gc.c:1470
push_root at d:\code\msys64\home\tony\julia\src\gc.c:1739
gc_push_root at d:\code\msys64\home\tony\julia\src\gc.c:1470
gc_mark_stack at d:\code\msys64\home\tony\julia\src\gc.c:1509
gc_mark_task_stack at d:\code\msys64\home\tony\julia\src\gc.c:1563
gc_mark_task at d:\code\msys64\home\tony\julia\src\gc.c:1584
push_root at d:\code\msys64\home\tony\julia\src\gc.c:1706
gc_push_root at d:\code\msys64\home\tony\julia\src\gc.c:1470
pre_mark at d:\code\msys64\home\tony\julia\src\gc.c:1818
jl_gc_collect at d:\code\msys64\home\tony\julia\src\gc.c:2212
__pool_alloc at d:\code\msys64\home\tony\julia\src\gc.c:1040
_pool_alloc at d:\code\msys64\home\tony\julia\src\gc.c:1086
alloc_3w at d:\code\msys64\home\tony\julia\src\gc.c:2469
newobj at d:\code\msys64\home\tony\julia\src\julia_internal.h:26
jl_alloc_svec_uninit at d:\code\msys64\home\tony\julia\src\simplevector.c:56
inst_datatype at d:\code\msys64\home\tony\julia\src\jltypes.c:1962
inst_type_w_ at d:\code\msys64\home\tony\julia\src\jltypes.c:2212
jl_instantiate_type_with at d:\code\msys64\home\tony\julia\src\jltypes.c:2220
jl_apply_type_ at d:\code\msys64\home\tony\julia\src\jltypes.c:1699
jl_f_instantiate_type at d:\code\msys64\home\tony\julia\src\builtins.c:973
call at base.jl:294
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1743
f_argnames at inference.jl:1242
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
typeinf_uncached at inference.jl:1396
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
typeinf at inference.jl:1307
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
typeinf at inference.jl:1257
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
abstract_call_gf at inference.jl:696
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1743
abstract_call at inference.jl:823
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
abstract_eval_call at inference.jl:904
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
abstract_eval at inference.jl:961
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
abstract_eval_call at inference.jl:881
jl_apply at d:\code\msys64\home\tony\julia\src\julia.h:1288
jl_apply_unspecialized at d:\code\msys64\home\tony\julia\src\gf.c:29
jl_apply_generic at d:\code\msys64\home\tony\julia\src\gf.c:1740
abstract_eval at inference.jl:961
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
May 13, 2015
Author
Member
you'll perhaps need to put equivalent padding on the bigval_t struct and gcval_t struct to keep them all in sync. i'm pretty sure this isn't the right approach however and you'll need to track down exactly why msvc is not compiling this code the same as gcc/clang.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
May 13, 2015
Contributor
Did the offsets look right? If I had to guess it might be the bit fields not playing correctly with uintptr_t
? https://msdn.microsoft.com/en-us/library/yszfawxh.aspx
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
Jun 19, 2015
Author
Member
what is sizeof(jl_taggedvalue_t)
(expected value: 8
) and sizeof(jl_value_t)
(expected value: 0
)? perhaps msvc is does not like that zero?
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
Jun 19, 2015
Contributor
0:000> ?? sizeof(jl_taggedvalue_t)
unsigned int64 0x10
0:000> ?? sizeof(jl_value_t)
unsigned int64 8
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
Jun 19, 2015
Author
Member
THAT'S IT! both of those have been computed wrong. most of the system should still hold together in that case, except that the jmpbuf struct will get misaligned, and when you hit a task switch ... SEGFAULT
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
Jun 19, 2015
Contributor
It's highly likely that I did something hacky and wrong somewhere (4c06a18 maybe?) to satisfy the compilation, that broke these assumptions. It's pretty easy to test any fixes you may have, master has been building and bootstrapping (with one tiny int128 patch below, compiler-rt may fix this for us eventually) fine with msvc for a few weeks now.
diff --git a/base/string.jl b/base/string.jl
index 1542296..7b1f9ce 100644
--- a/base/string.jl
+++ b/base/string.jl
@@ -1562,7 +1562,7 @@ function tryparse_internal{T<:Integer}(::Type{T}, s::AbstractString, startpos::I
end
base = convert(T,base)
- m::T = div(typemax(T)-base+1,base)
+ m::T = T===UInt128 || T===Int128 ? typemax(T) : div(typemax(T)-base+1,base)
n::T = 0
while n <= m
d::T = '0' <= c <= '9' ? c-'0' :
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
Jun 19, 2015
Author
Member
strictly speaking, the result was undefined (http://stackoverflow.com/questions/1626446/what-is-the-size-of-an-empty-struct-in-c). GCC just gave a good answer.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
Jun 19, 2015
Contributor
Hrm. Well if there's any hope of achieving the same end result without requiring a GCC extension, I'm all ears.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
Jun 19, 2015
Author
Member
i think it's safe enough to just go through and replace them with a constant #define sizeof_jl_taggedvalue_t (8)
statement
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
Jun 19, 2015
Contributor
Good man! That did it, we have an MSVC-built REPL again! That doesn't seem like the most portable of hardcodings though, is it 2x pointer size? I don't have a 32 bit MSVC 2013 build of LLVM to try there.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
Jun 19, 2015
Author
Member
i guess numbers test fails because it's missing int128 support?
sizeof_jl_tagged_value_t = sizeof(void*)
sizeof_jl_value_t = 0 (or #undef)
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
tkelman
Jun 19, 2015
Contributor
I didn't seem to need the latter? I'll open a PR shortly, should I make that second change too?
This comment has been minimized.
This comment has been minimized.
Sorry, something went wrong.
vtjnash
Jun 19, 2015
Author
Member
it's not much necessary. it looks like it is just used where we try to describe the jl_value_t to DWARF.
1 comment
on commit 8b8b261
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎆
Any idea how to do this for MSVC? I get segfaults in
jl_setjmp
on starting the repl ever since this commit (applying https://gist.github.com/ab1d03d18a51e2acc874 to get it to build and finish bootstrapping)