On 2/13/2012 11:32 PM, Jacob Carlborg wrote:
> On 13 Feb, 2012,at 11:37 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
>
>> What exact version of dmd/druntime/phobos are you using?
>> Is this related to the GC locking changes?
> These changes:
>
> https://github.com/D-Programming-Language/druntime/commit/f4d798b0138030b80c8d898e237948046e191c0d
>
> Do not appear to be present in the latest beta, at least not in the druntime sources that are bundled.
>

So are you saying the problem you're having occurs with the beta, or with the latest version you got from github?

On 14 Feb, 2012,at 08:58 AM, Walter Bright <walter at digitalmars.com> wrote:

>
>
> On 2/13/2012 11:32 PM, Jacob Carlborg wrote:
> > On 13 Feb, 2012,at 11:37 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
> >
> >> What exact version of dmd/druntime/phobos are you using?
> >> Is this related to the GC locking changes?
> > These changes:
> >
> > https://github.com/D-Programming-Language/druntime/commit/f4d798b0138030b80c8d898e237948046e191c0d
> >
> > Do not appear to be present in the latest beta, at least not in the druntime sources that are bundled.
> >

With the beta.

--
/Jacob Carlborg?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120214/0d6260c5/attachment-0001.html>

> I'm seeing some general problem with array appending. Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending.
>

Any futher insights on this?
Even a bigger test case would be helpful if it reproduces the error.

On 02/13/2012 12:23 PM, Walter Bright wrote:
>
>
> On 2/13/2012 3:05 AM, Daniel Murphy wrote:
>> Please take a look at the message I left on https://github.com/D-Programming-Language/dmd/commit/f330b950171adb67d2b648885c528b2fd5909130#comments
>>
>>
>> I think it's a regression.
>>
>
> I have a hard time mentally connecting which name is used on the mailing list with which pseudonym on github. I know if I click on yebblies I get Daniel Murphy, but it would be more convenient if you used DanielMurphy as the github handle. This applies to everyone.
>
> And btw, using your own name for the commits will increase your professional ranking in Google searches, as Google will be able to find your contributions easily :-).

As far as most of the people who I interact with online go, if I started using my legal name they mostly wouldn't know who I am.

Consistency is king.

On 15 Feb, 2012,at 01:35 AM, Martin Nowak <dawg at dawgfoto.de> wrote:

> > I'm seeing some general problem with array appending. Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending.
> >
>
> Any futher insights on this?
> Even a bigger test case would be helpful if it reproduces the error.

Unfortunately no. I have a big test case:

This example: http://pastebin.com/k1QQnhEp
together with Orange: https://github.com/jacob-carlborg/orange

Just place the example in the same folder as Orange and run it with RDMD.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120215/6473f447/attachment-0001.html>

On Wed, 15 Feb 2012 08:52:52 +0100, Jacob Carlborg <doob at me.com> wrote:

> On 15 Feb, 2012,at 01:35 AM, Martin Nowak <dawg at dawgfoto.de> wrote:
>
>> > I'm seeing some general problem with array appending. Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending.
>> >
>>
>> Any futher insights on this?
>> Even a bigger test case would be helpful if it reproduces the error.
> Unfortunately no. I have a big test case:
>
> This example: http://pastebin.com/k1QQnhEp
> together with Orange: https://github.com/jacob-carlborg/orange
>
> Just place the example in the same folder as Orange and run it with RDMD.?

I get an infinite recursion.

Starting from
Serializer.d(1107): return deserializeObject!(T)(keyOrId); // with keyOrId
being "refme" the recursive field name in Foo

#29 0x000000000040a947 in
orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal()
(this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at
orange/serialization/Serializer.d:1104
#30 0x000000000040ad53 in
orange.serialization.Serializer.Serializer.__T29objectStructDeserializeHelperTC4main3FooZ.objectStructDeserializeHelper()
(this=0x8006c4a00, value=<error reading variable>) at
orange/serialization/Serializer.d:1482
#31 0x000000000040ac7e in
orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject()
(this=0x80128b1c0) at orange/serialization/Serializer.d:1181
#32 0x000000000040a89f in
orange.serialization.Serializer.Serializer.__T13triggerEventsTC4main3FooZ.triggerEvents()
(this=0x8006c4a00, dg=0x000000000040aa94000000080128b1c0,
value=0x80128c860) at orange/serialization/Serializer.d:1749
#33 0x000000000040aa8b in
orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject()
(this=0x80128b1c0) at orange/serialization/Serializer.d:1153
#34 0x00000000004061cb in
orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject()
(this=0x80128b140) at orange/serialization/archives/XmlArchive.d:1366
#35 0x0000000000417cdb in
orange.util.Use.__T7restoreTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.restore()
(this=0x0, value=0x8006c6f50, dg=0x000000000040603c000000080128b140) at
orange/util/Use.d:162
#36 0x0000000000417b94 in
orange.util.Use.__T13RestoreStructTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.RestoreStruct.opIn()
(this=0x7fffffbffc20, deleg=0x000000000040603c000000080128b140) at
orange/util/Use.d:127
#37 0x0000000000406035 in
orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject()
(this=0x8006c6f00, dg=..., result=0x80128b1c8, id=0x7fffffbffc98,
key=0x0000000000459eb00000000000000005) at
orange/serialization/archives/XmlArchive.d:1342
#38 0x000000000040aa2d in
orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject()
(this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at
orange/serialization/Serializer.d:1152
#39 0x000000000040a947 in
orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal()
(this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at
orange/serialization/Serializer.d:1104


By the way, there are about 3 or 4 delegate context allocations within this cycles.

On 15 Feb, 2012,at 11:25 AM, Martin Nowak <dawg at dawgfoto.de> wrote:

> On Wed, 15 Feb 2012 08:52:52 +0100, Jacob Carlborg <doob at me.com> wrote:
>
> > On 15 Feb, 2012,at 01:35 AM, Martin Nowak <dawg at dawgfoto.de> wrote:
> >
> >> > I'm seeing some general problem with array appending Removing the append in the above method and the segfault moves to an other part of the code, which uses array appending.
> >> >
> >>
> >> Any futher insights on this?
> >> Even a bigger test case would be helpful if it reproduces the error.
> > Unfortunately no. I have a big test case:
> >
> > This example: http://pastebin.com/k1QQnhEp
> > together with Orange: https://github.com/jacob-carlborg/orange
> >
> > Just place the example in the same folder as Orange and run it with RDMD.?
>
> I get an infinite recursion.
>
> Starting from
> Serializer.d(1107): return deserializeObject!(T)(keyOrId); // with keyOrId
> being "refme" the recursive field name in Foo
>
> #29 0x000000000040a947 in
> orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal()
> (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at
> orange/serialization/Serializer.d:1104
> #30 0x000000000040ad53 in
> orange.serialization.Serializer.Serializer.__T29objectStructDeserializeHelperTC4main3FooZ.objectStructDeserializeHelper()
> (this=0x8006c4a00, value=<error reading variable>) at
> orange/serialization/Serializer.d:1482
> #31 0x000000000040ac7e in
> orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject()
> (this=0x80128b1c0) at orange/serialization/Serializer.d:1181
> #32 0x000000000040a89f in
> orange.serialization.Serializer.Serializer.__T13triggerEventsTC4main3FooZ.triggerEvents()
> (this=0x8006c4a00, dg=0x000000000040aa94000000080128b1c0,
> value=0x80128c860) at orange/serialization/Serializer.d:1749
> #33 0x000000000040aa8b in
> orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject()
> (this=0x80128b1c0) at orange/serialization/Serializer.d:1153
> #34 0x00000000004061cb in
> orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject()
> (this=0x80128b140) at orange/serialization/archives/XmlArchive.d:1366
> #35 0x0000000000417cdb in
> orange.util.Use.__T7restoreTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.restore()
> (this=0x0, value=0x8006c6f50, dg=0x000000000040603c000000080128b140) at
> orange/util/Use.d:162
> #36 0x0000000000417b94 in
> orange.util.Use.__T13RestoreStructTvTS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZ.RestoreStruct.opIn()
> (this=0x7fffffbffc20, deleg=0x000000000040603c000000080128b140) at
> orange/util/Use.d:127
> #37 0x0000000000406035 in
> orange.serialization.archives.XmlArchive.__T10XmlArchiveTaZ.XmlArchive.unarchiveObject()
> (this=0x8006c6f00, dg=..., result=0x80128b1c8, id=0x7fffffbffc98,
> key=0x0000000000459eb00000000000000005) at
> orange/serialization/archives/XmlArchive.d:1342
> #38 0x000000000040aa2d in
> orange.serialization.Serializer.Serializer.__T17deserializeObjectTC4main3FooTAyaZ.deserializeObject()
> (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at
> orange/serialization/Serializer.d:1152
> #39 0x000000000040a947 in
> orange.serialization.Serializer.Serializer.__T19deserializeInternalTC4main3FooTAyaZ.deserializeInternal()
> (this=0x8006c4a00, keyOrId=0x0000000000459eb00000000000000005) at
> orange/serialization/Serializer.d:1104
>
>
> By the way, there are about 3 or 4 delegate context allocations within this cycles.

Yeah, but the top of the backtrace looks like this:

(gdb) bt
#0  0x0000000100043f5c in D2gc3gcx3Gcx7getInfoMFPvZS2gc3gcx7BlkInfo ()
#1  0x0000000100042ecd in D2gc3gcx2GC11queryNoSyncMFPvZS2gc3gcx7BlkInfo ()
#2  0x0000000100042e1d in D2gc3gcx2GC5queryMFPvZS2gc3gcx7BlkInfo ()
#3  0x0000000100041400 in gc_query ()
#4  0x000000010004ae25 in _d_arrayappendcTX ()
#5  0x000000010000b7fa in D6orange3xml9PhobosXml7Element10attributesMFZAC6orange3xml9PhobosXml9Attribute17__foreachbody1521MFKAyaKAyaZi ()
#6  0x0000000100046ec6 in _aaApply2 ()
#7  0x000000010000b770 in D6orange3xml9PhobosXml7Element10attributesMFZAC6orange3xml9PhobosXml9Attribute ()
#8  0x0000000100001c83 in D6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4Node10attributesMFZS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument12VisitorProxy ()
#9  0x000000010000205e in D6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument10QueryProxy9attributeMFDFS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument4NodeZbZS6orange3xml11XmlDocument19__T11XmlDocumentTaZ11XmlDocument10QueryProxy

At number 4 there's a call to _d_arrayappendcTX, which would be the array appending in this method: https://github.com/jacob-carlborg/orange/blob/master/orange/xml/PhobosXml.d#L764

If I remove that array append then? I get the same error somewhere else in the code.

--
/Jacob Carlborg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120215/8105e09c/attachment.html>

> Yeah, but the top of the backtrace looks like this:
>
It's a stack overflow, i.e. it will segfault wherever it wants to.

On 15 Feb, 2012,at 01:24 PM, Martin Nowak <dawg at dawgfoto.de> wrote:

> > Yeah, but the top of the backtrace looks like this:
> >
> It's a stack overflow, i.e. it will segfault wherever it wants to.

Then the question is?. Is this a bug in DMD or in my code since it worked with DMD 2.057.

--
/Jacob Carlborg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20120215/36025381/attachment-0001.html>

On Wed, 15 Feb 2012 14:05:35 +0100, Jacob Carlborg <doob at me.com> wrote:

> On 15 Feb, 2012,at 01:24 PM, Martin Nowak <dawg at dawgfoto.de> wrote:
>
>> > Yeah, but the top of the backtrace looks like this:
>> >
>> It's a stack overflow, i.e. it will segfault wherever it wants to.
> Then the question is?. Is this a bug in DMD or in my code since it worked with DMD 2.057.
>
> --
> /Jacob Carlborg

I get that stack overflow with 2.057 too.