On Monday, 13 March 2017 at 19:40:30 UTC, Stefan Koch wrote:
> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>> [ ... ]
>
> I just fixed a bug in ref support;
> It should now work with slices.
>
> I also made it _slightly_ easier to make ABI changes for slice, since I expect the structure to change as soon as concat support is added.
> (e.g. slices will get a refcount, capacity and an origin ptr)

Bad news.
Array expansion via assignment to length regressed.
Fixing this is surprisingly time intensive.
.... I am just not seeing where it's going wrong.

It seems to use completely bogus offsets ... causing it to read from uninitialized memory.

On Tue, Mar 14, 2017 at 03:26:44PM +0000, Stefan Koch via Digitalmars-d wrote: [...]
> Bad news.
> Array expansion via assignment to length regressed.
> Fixing this is surprisingly time intensive.
> .... I am just not seeing where it's going wrong.
> 
> It seems to use completely bogus offsets ... causing it to read from uninitialized memory.

Sounds like there's a pointer bug / stack overflow / buffer overflow somewhere.  Just my gut feeling from having faced similar bugs in my career. Unfortunately, these kinds of bugs are usually very difficult to trace, because the root cause can be very far away from where the symptoms show up, and can come from completely unrelated code.

One way that sometimes works (but not always) is to try to shuffle the stack by moving functions / local variables around to see if the symptoms change. That may yield some clues as to the nature of the problem.  But that's just a shot in the dark... generally these kinds of bugs are very hard to trace.

Or maybe carefully step through the code starting from the length assignment in a debugger and see if any of the variables seem to have strange values. Sometimes the code immediately following is fine (inserting printf's of the buffer may indicate correct values) but it's something that happens afterwards that screws it up.

Or, possibly, the state is already messed up before the length assignment... in which case it would be far more difficult to trace. :-(


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On Tuesday, 14 March 2017 at 16:42:01 UTC, H. S. Teoh wrote:
> [ ... ]

@ H.S.Teoh
Thanks for your advice.
Since I am running my own bytecode I am quite sure that there is no memory corruption going on.
It has to do with the recent ABI changes.

--
I just made strings use the same representation as every other slice,
Meaning soon we can use std.utf.decode for correct string-foreach :)
After that it is not a big step to supporting string concat.

On 3/14/17 4:26 PM, Stefan Koch wrote:
> On Monday, 13 March 2017 at 19:40:30 UTC, Stefan Koch wrote:
>> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>>> [ ... ]
>>
>> I just fixed a bug in ref support;
>> It should now work with slices.
>>
>> I also made it _slightly_ easier to make ABI changes for slice, since
>> I expect the structure to change as soon as concat support is added.
>> (e.g. slices will get a refcount, capacity and an origin ptr)
>
> Bad news.
> Array expansion via assignment to length regressed.
> Fixing this is surprisingly time intensive.
> .... I am just not seeing where it's going wrong.
>
> It seems to use completely bogus offsets ... causing it to read from
> uninitialized memory.
>

Time to try valgrind ? Last time I checked it worked just fine with D.

---
Dmitry Olshansky

On Tuesday, 14 March 2017 at 21:53:29 UTC, Dmitry Olshansky wrote:
> On 3/14/17 4:26 PM, Stefan Koch wrote:
>> On Monday, 13 March 2017 at 19:40:30 UTC, Stefan Koch wrote:
>>> On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
>>>> [ ... ]
>>>
>>> I just fixed a bug in ref support;
>>> It should now work with slices.
>>>
>>> I also made it _slightly_ easier to make ABI changes for slice, since
>>> I expect the structure to change as soon as concat support is added.
>>> (e.g. slices will get a refcount, capacity and an origin ptr)
>>
>> Bad news.
>> Array expansion via assignment to length regressed.
>> Fixing this is surprisingly time intensive.
>> .... I am just not seeing where it's going wrong.
>>
>> It seems to use completely bogus offsets ... causing it to read from
>> uninitialized memory.
>>
>
> Time to try valgrind ? Last time I checked it worked just fine with D.
>
> ---
> Dmitry Olshansky

When I talk about uninitialized memory I mean memory inside the VM, which is untouched.
The Problem is a problem with bytecode generation, not the execution.
The code executes as it should, but the generated code is invalid.

On Tuesday, 14 March 2017 at 21:53:29 UTC, Dmitry Olshansky wrote:
> [...]
>>
>
> Time to try valgrind ? Last time I checked it worked just fine with D.

Valgrind 3.12.0, at least, works perfectly with dmd&ldc.
One just has to remember to suppress the (static) memory leak in druntime[1]

[1] https://github.com/dlang/druntime/pull/1557

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:
> [ ... ]

String Slicing is in!
The following code will now compile with newCTFE.

string slice(string s, uint lwr, uint upr)
{
    return s[lwr .. upr];
}

static assert(slice("Hello World", 6, 11) == "World");

On Wednesday, 15 March 2017 at 13:49:43 UTC, Stefan Koch wrote:
> String Slicing is in!

Great! What remains?

On Wednesday, 15 March 2017 at 15:49:59 UTC, Nordlöw wrote:
> On Wednesday, 15 March 2017 at 13:49:43 UTC, Stefan Koch wrote:
>> String Slicing is in!
>
> Great! What remains?

Unsupported Features include :

 - Unicode/Auto-decoding support.
NOTE: foreach(char c; string) { ... } will work since it does not auto-decode.

 - Floating point.
 - Classes
 - unions
 - structs containing other structs.
 - arrays of structs
 - arrays of arrays
 - || and &&
 - ref return (though I doubt it's needed)
 - references of 64bit values

And maybe other I cannot think of right now.

On Wednesday, 15 March 2017 at 15:59:46 UTC, Stefan Koch wrote:
> On Wednesday, 15 March 2017 at 15:49:59 UTC, Nordlöw wrote:
>> On Wednesday, 15 March 2017 at 13:49:43 UTC, Stefan Koch wrote:
>>> String Slicing is in!
>>
>> Great! What remains?
>
> Unsupported Features include :
>
>  - Unicode/Auto-decoding support.
> NOTE: foreach(char c; string) { ... } will work since it does not auto-decode.
>
>  - Floating point.
>  - Classes
>  - unions
>  - structs containing other structs.
>  - arrays of structs
>  - arrays of arrays
>  - || and &&
>  - ref return (though I doubt it's needed)
>  - references of 64bit values
>
> And maybe other I cannot think of right now.

slice expansion.
and string-foreach caused dmd to miscomplie itself ... *sigh*

So no string-foreach for now;