On Mar 4, 2013 2:11 AM, "deadalnix" <deadalnix@gmail.com> wrote:
>
> On Sunday, 3 March 2013 at 17:03:24 UTC, Iain Buclaw wrote:
>>
>> On Mar 3, 2013 5:01 PM, "deadalnix" <deadalnix@gmail.com> wrote:
>>>
>>>
>>> On Sunday, 3 March 2013 at 16:51:15 UTC, Iain Buclaw wrote:
>>>>
>>>>
>>>> Is this a dmd thing, or does it affect other compilers? (don't have a
>>
>> laptop to test at the moment).
>>>>
>>>>
>>>
>>> I don't know, the code is not compilable with 2.060 (or 2.061) so I'm
>>
>> unable to test how gdc does on that one.
>>
>> GDC has been on 2.062 frontend for at least a fortnight. I know I don't announce these things, but am still busy working on next set of refactoring.
>>
>> Regards
>
>
> Tested, the corruption don't appear with GDC. Good job !

Excellente!  :o)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
...
> Obviously, the program segfault soon after that.
>
> It sounds like some memory corruption occurs under the hood. What can I do to work around that bug and to help solving it ?

Have you compiled this with the latest gitHEAD ? Several very nasty wrong-code bugs were fixed very recently (eg, bug 9568).

On Monday, 4 March 2013 at 10:55:58 UTC, Don wrote:
> On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
> ...
>> Obviously, the program segfault soon after that.
>>
>> It sounds like some memory corruption occurs under the hood. What can I do to work around that bug and to help solving it ?
>
> Have you compiled this with the latest gitHEAD ? Several very nasty wrong-code bugs were fixed very recently (eg, bug 9568).

No luck. I just tested it and it doesn't work.

On Monday, 4 March 2013 at 14:21:11 UTC, deadalnix wrote:
> On Monday, 4 March 2013 at 10:55:58 UTC, Don wrote:
>> On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
>> ...
>>> Obviously, the program segfault soon after that.
>>>
>>> It sounds like some memory corruption occurs under the hood. What can I do to work around that bug and to help solving it ?
>>
>> Have you compiled this with the latest gitHEAD ? Several very nasty wrong-code bugs were fixed very recently (eg, bug 9568).
>
> No luck. I just tested it and it doesn't work.

I did some investigation yesterday. It seems that the frame pointer that is passed when calling the closure is not always the right one.

I now can catch the problem as soon as it occurs. I'll try to reduce it to a simpler test case, but it seems really difficult.

On Thursday, 7 March 2013 at 04:21:01 UTC, deadalnix wrote:
> On Monday, 4 March 2013 at 14:21:11 UTC, deadalnix wrote:
>> On Monday, 4 March 2013 at 10:55:58 UTC, Don wrote:
>>> On Sunday, 3 March 2013 at 16:48:32 UTC, deadalnix wrote:
>>> ...
>>>> Obviously, the program segfault soon after that.
>>>>
>>>> It sounds like some memory corruption occurs under the hood. What can I do to work around that bug and to help solving it ?
>>>
>>> Have you compiled this with the latest gitHEAD ? Several very nasty wrong-code bugs were fixed very recently (eg, bug 9568).
>>
>> No luck. I just tested it and it doesn't work.
>
> I did some investigation yesterday. It seems that the frame pointer that is passed when calling the closure is not always the right one.
>
> I now can catch the problem as soon as it occurs. I'll try to reduce it to a simpler test case, but it seems really difficult.

Sooooooo,

I have a struct. The struct have a context pointer. I have this method :

@property
auto save() inout {
	return inout(Lexer)(t, r.save, line, index);
}

The context pointer IS NOT COPIED.

Fixed it that way :

@property
auto save() inout {
	// XXX: dmd bug, context pointer isn't copied properly
	// doing it manualy using black magic.
	// Context pointer is the last element of the struct. Here in position 9.
	auto ret = inout(Lexer)(t, r.save, line, index);
	(cast(void**) &ret)[9] = (cast(void**) &this)[9];
	
	return ret;
}

Very scary that I have to do that kind of things.

On Friday, 8 March 2013 at 16:25:56 UTC, deadalnix wrote:
> Sooooooo,
>
> I have a struct. The struct have a context pointer. I have this method :
>
> @property
> auto save() inout {
> 	return inout(Lexer)(t, r.save, line, index);
> }
>
> The context pointer IS NOT COPIED.
>
> Fixed it that way :
>
> @property
> auto save() inout {
> 	// XXX: dmd bug, context pointer isn't copied properly
> 	// doing it manualy using black magic.
> 	// Context pointer is the last element of the struct. Here in position 9.
> 	auto ret = inout(Lexer)(t, r.save, line, index);
> 	(cast(void**) &ret)[9] = (cast(void**) &this)[9];
> 	
> 	return ret;
> }
>
> Very scary that I have to do that kind of things.

Is this a know bug ? Come on, this is a really bad bug, not the type of thing that can be ignored !

On Sunday, 10 March 2013 at 19:11:07 UTC, deadalnix wrote:
> On Friday, 8 March 2013 at 16:25:56 UTC, deadalnix wrote:
>> Sooooooo,
>>
>> I have a struct. The struct have a context pointer. I have this method :
>>
>> @property
>> auto save() inout {
>> 	return inout(Lexer)(t, r.save, line, index);
>> }
>>
>> The context pointer IS NOT COPIED.
>>
>> Fixed it that way :
>>
>> @property
>> auto save() inout {
>> 	// XXX: dmd bug, context pointer isn't copied properly
>> 	// doing it manualy using black magic.
>> 	// Context pointer is the last element of the struct. Here in position 9.
>> 	auto ret = inout(Lexer)(t, r.save, line, index);
>> 	(cast(void**) &ret)[9] = (cast(void**) &this)[9];
>> 	
>> 	return ret;
>> }
>>
>> Very scary that I have to do that kind of things.
>
> Is this a know bug ? Come on, this is a really bad bug, not the type of thing that can be ignored !

(i do not know such bug)

This code works:

auto foo()
{
    int i;
    struct S
    {
        int a, b, c;
        int foo() { return i; }
        auto save() inout {
            return inout (S)(i,i,i);
        }
    }
    return S();
}

void main()
{
    auto s1 = foo();
    auto s2 = s1.save();
    assert(s2.foo() is 0);
}

So, from your description I cannot reproduce the bug. Reducing is time consuming and not pleasant activity, but it is sometimes a necessity.

On 3/10/2013 12:11 PM, deadalnix wrote:
> On Friday, 8 March 2013 at 16:25:56 UTC, deadalnix wrote:
>> Sooooooo,
>>
>> I have a struct. The struct have a context pointer. I have this method :
>>
>> @property
>> auto save() inout {
>>     return inout(Lexer)(t, r.save, line, index);
>> }
>>
>> The context pointer IS NOT COPIED.
>>
>> Fixed it that way :
>>
>> @property
>> auto save() inout {
>>     // XXX: dmd bug, context pointer isn't copied properly
>>     // doing it manualy using black magic.
>>     // Context pointer is the last element of the struct. Here in position 9.
>>     auto ret = inout(Lexer)(t, r.save, line, index);
>>     (cast(void**) &ret)[9] = (cast(void**) &this)[9];
>> 
>>     return ret;
>> }
>>
>> Very scary that I have to do that kind of things.
> 
> Is this a know bug ? Come on, this is a really bad bug, not the type of thing that can be ignored !

Is it in bugzilla?  The newsgroups are a bad place to be reporting bugs.

On 3/8/2013 8:25 AM, deadalnix wrote:
> I have a struct. The struct have a context pointer. I have this method :
>
> @property
> auto save() inout {
>      return inout(Lexer)(t, r.save, line, index);
> }
>
> The context pointer IS NOT COPIED.
>
> Fixed it that way :
>
> @property
> auto save() inout {
>      // XXX: dmd bug, context pointer isn't copied properly
>      // doing it manualy using black magic.
>      // Context pointer is the last element of the struct. Here in position 9.
>      auto ret = inout(Lexer)(t, r.save, line, index);
>      (cast(void**) &ret)[9] = (cast(void**) &this)[9];
>
>      return ret;
> }

1. We can't do anything with code snippets like that. A complete, compilable example is necessary.

2. Such bug reports, along with the complete example demonstrating it, needs to go into bugzilla, not here.

On Sunday, 10 March 2013 at 21:01:11 UTC, Walter Bright wrote:
> On 3/8/2013 8:25 AM, deadalnix wrote:
>> I have a struct. The struct have a context pointer. I have this method :
>>
>> @property
>> auto save() inout {
>>     return inout(Lexer)(t, r.save, line, index);
>> }
>>
>> The context pointer IS NOT COPIED.
>>
>> Fixed it that way :
>>
>> @property
>> auto save() inout {
>>     // XXX: dmd bug, context pointer isn't copied properly
>>     // doing it manualy using black magic.
>>     // Context pointer is the last element of the struct. Here in position 9.
>>     auto ret = inout(Lexer)(t, r.save, line, index);
>>     (cast(void**) &ret)[9] = (cast(void**) &this)[9];
>>
>>     return ret;
>> }
>
> 1. We can't do anything with code snippets like that. A complete, compilable example is necessary.
>
> 2. Such bug reports, along with the complete example demonstrating it, needs to go into bugzilla, not here.

http://d.puremagic.com/issues/show_bug.cgi?id=9685

Isn't it an already known bug ?