Bug 18814 – Segmentation Fault in GC From writeln Call

Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P1
Component
druntime
Product
D
Version
D2
Platform
All
OS
All
Creation time
2018-04-30T19:17:06Z
Last change time
2018-04-30T20:02:34Z
Assigned to
No Owner
Creator
Jack Stouffer

Comments

Comment #0 by jack — 2018-04-30T19:17:06Z
Code reduced via dustmite main.d ========= import std.traits; import std.stdio; /** * Custom `string` type optimized for both small sizes and for appending * large amounts of data. */ struct String { /// ditto ref opOpAssign(string op, R)(R r) { convertToBig(); large.ptr[large.len .. r.length] = r; } ubyte isBig() { return small.slen; } void convertToBig() { import core.memory; char* p = cast(char*) GC.malloc(GC.BlkAttr.NO_SCAN); large.ptr = p; } struct Small { ubyte slen; } struct Large { size_t len; char* ptr; } Small small; Large large; } unittest { auto a = String(); a ~= " test test test test test"; writeln(a); } ========= $ dmd -unittest -main -run main.d String(Small(0), Large(0, 10AB9E000)) 0 dmd_runO05sQ2 0x000000010aacf6c8 _D4core7runtime18runModuleUnitTestsUZ19unittestSegvHandlerUNbNiiPSQCm3sys5posix6signal9siginfo_tPvZv + 56 1 libsystem_platform.dylib 0x00007fff512c1f5a _sigtramp + 26 2 ??? 0x000000011a8e9088 0x0 + 4740518024 3 dmd_runO05sQ2 0x000000010aadc8a7 _D2gc4impl12conservativeQw14ConservativeGC__T9runLockedS_DQCeQCeQCcQCnQBs12mallocNoSyncMFNbmkKmxC8TypeInfoZPvS_DQEgQEgQEeQEp10mallocTimelS_DQFiQFiQFgQFr10numMallocslTmTkTmTxQCzZQFcMFNbKmKkKmKxQDsZQDl + 147 4 dmd_runO05sQ2 0x000000010aad66c3 _D2gc4impl12conservativeQw14ConservativeGC6qallocMFNbmkxC8TypeInfoZS4core6memory8BlkInfo_ + 115 5 dmd_runO05sQ2 0x000000010aad58eb gc_qalloc + 51 6 dmd_runO05sQ2 0x000000010aacefec _D4core6memory2GC6qallocFNaNbmkxC8TypeInfoZSQBqQBo8BlkInfo_ + 32 7 dmd_runO05sQ2 0x000000010aac07fa _D3std5array__T8AppenderTAaZQn13ensureAddableMFNaNbNemZv + 286 8 dmd_runO05sQ2 0x000000010aac0c7b _D3std5array__T8AppenderTAaZQn__T3putTAxaZQjMFQiZ10bigDataFunMFNaNbNemZQBu + 31 9 dmd_runO05sQ2 0x000000010aac0bcd _D3std5array__T8AppenderTAaZQn__T3putTAxaZQjMFNaNbNfQoZv + 33 10 dmd_runO05sQ2 0x000000010aac0ba8 _D3std5range10primitives__T5doPutTSQBh5array__T8AppenderTAaZQnTAxaZQBoFNaNbNfKQBsKQtZv + 28 11 dmd_runO05sQ2 0x000000010aac0b88 _D3std5range10primitives__T3putTSQBf5array__T8AppenderTAaZQnTAxaZQBmFNaNbNfKQBsQsZv + 28 12 dmd_runO05sQ2 0x000000010aac0a34 _D3std6format__T10FormatSpecTaZQp__T17writeUpToNextSpecTSQCd5array__T8AppenderTAaZQnZQBxMFNaNfKQBnZb + 184 13 dmd_runO05sQ2 0x000000010aab7c5b _D3std6format__T10FormatSpecTaZQp20__unittest_L1204_C11FNaNfZv + 95 14 dmd_runO05sQ2 0x000000010aab7446 _D4main9__modtestFZv + 14 15 dmd_runO05sQ2 0x000000010aacf720 _D4core7runtime18runModuleUnitTestsUZ14__foreachbody2MFPS6object10ModuleInfoZi + 56 16 dmd_runO05sQ2 0x000000010aac4953 _D6object10ModuleInfo7opApplyFMDFPSQBhQBdZiZ9__lambda2MFyPSQCfQCbZi + 35 17 dmd_runO05sQ2 0x000000010aae8ee6 _D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZ14__foreachbody2MFKSQCz19sections_osx_x86_6412SectionGroupZi + 86 18 dmd_runO05sQ2 0x000000010aae8e71 _D2rt5minfo17moduleinfos_applyFMDFyPS6object10ModuleInfoZiZi + 33 19 dmd_runO05sQ2 0x000000010aac492a _D6object10ModuleInfo7opApplyFMDFPSQBhQBdZiZi + 34 20 dmd_runO05sQ2 0x000000010aacf4d7 runModuleUnitTests + 335 21 dmd_runO05sQ2 0x000000010aae12c1 _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv + 37 22 dmd_runO05sQ2 0x000000010aae124c _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv + 32 23 dmd_runO05sQ2 0x000000010aae11ba _d_run_main + 486 24 dmd_runO05sQ2 0x000000010aab7468 main + 16 25 libdyld.dylib 0x00007fff50fb3015 start + 1 26 ??? 0x0000000000000001 0x0 + 1 Error: program killed by signal 11
Comment #1 by jack — 2018-04-30T19:18:12Z
Should mention $ dmd --version DMD64 D Compiler v2.079.1
Comment #2 by Marco.Leise — 2018-04-30T19:39:59Z
First thing that came to my mind ... there is suddenly an obvious GC bug exposed by writeln?! Probably more likely some custom stuff that overwrites internal data structures or something, let's look at the provided test case... GC.malloc(GC.BlkAttr.NO_SCAN); That does not look like the correct first argument to: https://dlang.org/phobos/core_memory.html#.GC.malloc Could you please give the amount of bytes you want to allocate and then post the corrected test case? ;)
Comment #3 by jack — 2018-04-30T19:43:56Z
(In reply to Marco Leise from comment #2) > First thing that came to my mind ... there is suddenly an obvious GC bug > exposed by writeln?! Probably more likely some custom stuff that overwrites > internal data structures or something, let's look at the provided test > case... > > GC.malloc(GC.BlkAttr.NO_SCAN); > > That does not look like the correct first argument to: > https://dlang.org/phobos/core_memory.html#.GC.malloc > > Could you please give the amount of bytes you want to allocate and then post > the corrected test case? ;) ========== import std.traits; import std.stdio; struct String { ref opOpAssign(string op, R)(R r) { convertToBig(); large.ptr[large.len .. r.length] = r; } ubyte isBig() { return small.slen; } void convertToBig() { import core.memory; char* p = cast(char*) GC.malloc(10, GC.BlkAttr.NO_SCAN); large.ptr = p; } struct Small { ubyte slen; } struct Large { size_t len; char* ptr; } Small small; Large large; } unittest { auto a = String(); a ~= " test test test test test"; writeln(a); } ==========
Comment #4 by Marco.Leise — 2018-04-30T19:56:54Z
You allocated 10 bytes for the string " test test test test test". Let me count ... 1 ... 2 ... 3 ... mmh ... no. If it was April 1st, ok, but it is close to May 1st.
Comment #5 by jack — 2018-04-30T20:02:34Z
(In reply to Marco Leise from comment #4) > You allocated 10 bytes for the string " test test test test test". Let me > count ... 1 ... 2 ... 3 ... mmh ... no. If it was April 1st, ok, but it is > close to May 1st. Reducing this bug isn't easy. I basically have to fight dustmite to not get rid of the actual bug and add in a new bug. If I'm able to get a good reduced test case I'll reopen.